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1 - INTRODUCTION 


INTRODUCTION 

A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK®  Guide)  - Fifth  Edition  provides  guidelines 
for  managing  individual  projects  and  defines  project  management  related  concepts.  It  also  describes  the  project 
management  life  cycle  and  its  related  processes,  as  well  as  the  project  life  cycle. 

The  PMBOK®  Guide  contains  the  globally  recognized  standard  and  guide  for  the  project  management  profession 
(found  in  Annex  A1).  A standard  is  a formal  document  that  describes  established  norms,  methods,  processes,  and 
practices.  As  with  other  professions,  the  knowledge  contained  in  this  standard  has  evolved  from  the  recognized 
good  practices  of  project  management  practitioners  who  have  contributed  to  the  development  of  this  standard. 

The  first  two  sections  of  the  PMBOK®  Guide  provide  an  introduction  to  key  concepts  in  the  project  management 
field.  Section  3 summarizes  the  Process  Groups  and  provides  an  overview  of  process  interactions  among  the  ten 
Knowledge  Areas  and  five  Process  Groups.  Sections  4 through  1 3 are  the  guide  to  the  project  management  body  of 
knowledge.  These  sections  expand  on  the  information  in  the  standard  by  describing  the  inputs  and  outputs,  as  well 
as  tools  and  techniques  used  in  managing  projects.  Annex  A1  is  the  standard  for  project  management  and  presents 
the  processes,  inputs,  and  outputs  that  are  considered  to  be  good  practice  on  most  projects  most  of  the  time. 

This  section  defines  several  key  terms  and  the  relationship  among  portfolio  management,  program  management, 
project  management  and  organizational  project  management.  An  overview  of  the  PMBOK®  Guide  is  found  within 
the  following  sections: 

1 .1  Purpose  of  the  PMBOK ® Guide 

1 .2  What  is  a Project? 

1 .3  What  is  Project  Management? 

1.4  Relationships  Among  Portfolio  Management,  Program  Management, 

Project  Management, and  Organizational  Project  Management 

1 .5  Relationship  Between  Project  Management,  Operations  Management, 
and  Organizational  Strategy 

1.6  Business  Value 

1 .7  Role  of  the  Project  Manager 

1 .8  Project  Management  Body  of  Knowledge 
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1 - INTRODUCTION 


1 .1  Purpose  of  the  PMBOK®  Guide 

The  acceptance  of  project  management  as  a profession  indicates  that  the  application  of  knowledge,  processes, 
skills,  tools,  and  techniques  can  have  a significant  impact  on  project  success.  The  PMBOK®  Guide  identifies  that 
subset  of  the  project  management  body  of  knowledge  that  is  generally  recognized  as  good  practice.  “Generally 
recognized”  means  the  knowledge  and  practices  described  are  applicable  to  most  projects  most  of  the  time,  and 
there  is  consensus  about  their  value  and  usefulness.  “Good  practice”  means  there  is  general  agreement  that  the 
application  of  the  knowledge,  skills,  tools,  and  techniques  can  enhance  the  chances  of  success  over  many  projects. 
“Good  practice”  does  not  mean  that  the  knowledge  described  should  always  be  applied  uniformly  to  all  projects;  the 
organization  and/or  project  management  team  is  responsible  for  determining  what  is  appropriate  for  any  given  project. 

The  PMBOK®  Guide  also  provides  and  promotes  a common  vocabulary  within  the  project  management 
profession  for  using  and  applying  project  management  concepts.  A common  vocabulary  is  an  essential  element  of 
a professional  discipline.  The  PMI  Lexicon  of  Project  Management  Terms  [I]1  provides  the  foundational  professional 
vocabulary  that  can  be  consistently  used  by  project,  program,  and  portfolio  managers  and  other  stakeholders. 

Annex  A1  is  a foundational  reference  for  PMI’s  project  management  professional  development  programs.  Annex 
A1  continues  to  evolve  along  with  the  profession,  and  is  therefore  not  all-inclusive;  this  standard  is  a guide  rather 
than  a specific  methodology.  One  can  use  different  methodologies  and  tools  (e.g.,  agile,  waterfall,  PRINCE2)  to 
implement  the  project  management  framework. 

In  addition  to  the  standards  that  establish  guidelines  for  project  management  processes,  the  Project  Management 
Institute  Code  of  Ethics  and  Professional  Conduct  [ 2]  guides  practitioners  of  the  profession  and  describes  the 
expectations  that  practitioners  should  hold  for  themselves  and  others.  The  Project  Management  Institute  Code 
of  Ethics  and  Professional  Conduct  is  specific  about  the  basic  obligation  of  responsibility,  respect,  fairness,  and 
honesty.  It  requires  that  practitioners  demonstrate  a commitment  to  ethical  and  professional  conduct.  It  carries 
the  obligation  to  comply  with  laws,  regulations,  and  organizational  and  professional  policies.  Practitioners  come 
from  diverse  backgrounds  and  cultures,  and  the  Project  Management  Institute  Code  of  Ethics  and  Professional 
Conduct  applies  globally.  When  interacting  with  any  stakeholder,  practitioners  should  be  committed  to  honest, 
responsible,  fair  practices  and  respectful  dealings.  Acceptance  of  the  code  is  essential  for  project  managers,  and  is 
a requirement  for  the  following  PMI®  exams: 

• Certified  Associate  in  Project  Management  (CAPM)® 

• Project  Management  Professional  (PMP)® 

• Program  Management  Professional  (PgMP)® 

• PMI  Agile  Certified  Practitioner  (PMI-ACP)SM 

• PMI  Risk  Management  Professional  (PMI-RMP)® 

• PMI  Scheduling  Professional  (PMI-SP)® 


^he  numbers  in  brackets  refer  to  the  list  of  references  at  the  end  of  this  standard. 
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1 .2  What  is  a Project? 

A project  is  a temporary  endeavor  undertaken  to  create  a unique  product,  service,  or  result.  The  temporary 
nature  of  projects  indicates  that  a project  has  a definite  beginning  and  end.  The  end  is  reached  when  the  project’s 
objectives  have  been  achieved  or  when  the  project  is  terminated  because  its  objectives  will  not  or  cannot  be  met, 
or  when  the  need  for  the  project  no  longer  exists.  A project  may  also  be  terminated  if  the  client  (customer,  sponsor, 
or  champion)  wishes  to  terminate  the  project.  Temporary  does  not  necessarily  mean  the  duration  of  the  project 
is  short.  It  refers  to  the  project’s  engagement  and  its  longevity.  Temporary  does  not  typically  apply  to  the  product, 
service,  or  result  created  by  the  project;  most  projects  are  undertaken  to  create  a lasting  outcome.  For  example,  a 
project  to  build  a national  monument  will  create  a result  expected  to  last  for  centuries.  Projects  can  also  have  social, 
economic,  and  environmental  impacts  that  far  outlive  the  projects  themselves. 

Every  project  creates  a unique  product,  service,  or  result.  The  outcome  of  the  project  may  be  tangible  or 
intangible.  Although  repetitive  elements  may  be  present  in  some  project  deliverables  and  activities,  this  repetition 
does  not  change  the  fundamental,  unique  characteristics  of  the  project  work.  For  example,  office  buildings  can 
be  constructed  with  the  same  or  similar  materials  and  by  the  same  or  different  teams.  Flowever,  each  building 
project  remains  unique  with  a different  location,  different  design,  different  circumstances  and  situations,  different 
stakeholders,  and  so  on. 

An  ongoing  work  effort  is  generally  a repetitive  process  that  follows  an  organization’s  existing  procedures. 
In  contrast,  because  of  the  unique  nature  of  projects,  there  may  be  uncertainties  or  differences  in  the  products, 
services,  or  results  that  the  project  creates.  Project  activities  can  be  new  to  members  of  a project  team,  which 
may  necessitate  more  dedicated  planning  than  other  routine  work.  In  addition,  projects  are  undertaken  at  all 
organizational  levels.  A project  can  involve  a single  individual  or  multiple  individuals,  a single  organizational  unit,  or 
multiple  organizational  units  from  multiple  organizations. 

A project  can  create: 

• A product  that  can  be  either  a component  of  another  item,  an  enhancement  of  an  item,  or  an  end  item 
in  itself; 

• A service  or  a capability  to  perform  a service  (e.g.,  a business  function  that  supports  production  or 
distribution); 

• An  improvement  in  the  existing  product  or  service  lines  (e.g.,  A Six  Sigma  project  undertaken  to  reduce 
defects);  or 

• A result,  such  as  an  outcome  or  document  (e.g.,  a research  project  that  develops  knowledge  that  can  be 
used  to  determine  whether  a trend  exists  or  a new  process  will  benefit  society). 
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Examples  of  projects  include,  but  are  not  limited  to: 

• Developing  a new  product,  service,  or  result; 

• Effecting  a change  in  the  structure,  processes,  staffing,  or  style  of  an  organization; 

• Developing  or  acquiring  a new  or  modified  information  system  (hardware  or  software); 

• Conducting  a research  effort  whose  outcome  will  be  aptly  recorded; 

• Constructing  a building,  industrial  plant,  or  infrastructure;  or 

• Implementing,  improving,  or  enhancing  existing  business  processes  and  procedures. 

1.2.1.  The  Relationships  Among  Portfolios,  Programs,  and  Projects 

The  relationship  among  portfolios,  programs,  and  projects  is  such  that  a portfolio  refers  to  a collection  of  projects, 
programs,  subportfolios,  and  operations  managed  as  a group  to  achieve  strategic  objectives.  Programs  are  grouped 
within  a portfolio  and  are  comprised  of  subprograms,  projects,  or  other  work  that  are  managed  in  a coordinated 
fashion  in  support  of  the  portfolio.  Individual  projects  that  are  either  within  or  outside  of  a program  are  still  considered 
part  of  a portfolio.  Although  the  projects  or  programs  within  the  portfolio  may  not  necessarily  be  interdependent  or 
directly  related,  they  are  linked  to  the  organization’s  strategic  plan  by  means  of  the  organization’s  portfolio. 

As  Figure  1-1  illustrates,  organizational  strategies  and  priorities  are  linked  and  have  relationships  between 
portfolios  and  programs,  and  between  programs  and  individual  projects.  Organizational  planning  impacts 
the  projects  by  means  of  project  prioritization  based  on  risk,  funding,  and  other  considerations  relevant  to  the 
organization’s  strategic  plan.  Organizational  planning  can  direct  the  management  of  resources,  and  support  for  the 
component  projects  on  the  basis  of  risk  categories,  specific  lines  of  business,  or  general  types  of  projects,  such  as 
infrastructure  and  process  improvement. 


4 ©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKB  Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


1 - INTRODUCTION 


Strategies  and  priorities 
Progressive  elaboration 
Governance 

Disposition  on  requested  changes 
Impacts  from  changes  in  other 
portfolios,  programs,  or  projects 


TT 


Performance  reports 
Change  requests  with 
impact  on  other  portfolios, 
programs,  or  projects 


Portfolio 

i 

• Strategies  and  priorities 

■ 

• Progressive  elaboration 

• Governance 

• Disposition  on  requested  changes 

• Impacts  from  changes  in  other 
portfolios,  programs,  or  projects 


• Performance  reports 

• Change  requests  with 
impact  on  other  portfolios, 
programs,  or  projects 


• Strategies  and  priorities 

• Progressive  elaboration 

• Governance 


2 • Disposition  on  requested  changes 

V. 

*.  2 • Impacts  from  changes  in  other 

j portfolios,  programs,  or  projects 

Programs 

• ••»•••••••••••»••••••••••••• 

w 

-x . • Performance  reports  •* 

• Change  requests  with  J 

impact  on  other  portfolios,  2 
programs,  or  projects  2 


Figure  1 -1 . Portfolio,  Program,  and  Project  Management  Interactions 

1 .3  What  is  Project  Management? 

Project  management  is  the  application  of  knowledge,  skills,  tools,  and  techniques  to  project  activities  to  meet  the 
project  requirements.  Project  management  is  accomplished  through  the  appropriate  application  and  integration  of 
the  47  logically  grouped  project  management  processes,  which  are  categorized  into  five  Process  Groups.  These  five 
Process  Groups  are: 

• Initiating, 

• Planning, 

• Executing, 

• Monitoring  and  Controlling,  and 

• Closing. 
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Managing  a project  typically  includes,  but  is  not  limited  to: 

• Identifying  requirements; 

• Addressing  the  various  needs,  concerns,  and  expectations  of  the  stakeholders  in  planning  and  executing 
the  project; 

• Setting  up,  maintaining,  and  carrying  out  communications  among  stakeholders  that  are  active,  effective, 
and  collaborative  in  nature; 

• Managing  stakeholders  towards  meeting  project  requirements  and  creating  project  deliverables; 

• Balancing  the  competing  project  constraints,  which  include,  but  are  not  limited  to: 

o Scope, 
o Quality, 
o Schedule, 
o Budget, 
o Resources,  and 
o Risks. 

The  specific  project  characteristics  and  circumstances  can  influence  the  constraints  on  which  the  project 
management  team  needs  to  focus. 

The  relationship  among  these  factors  is  such  that  if  any  one  factor  changes,  at  least  one  other  factor  is  likely 
to  be  affected.  For  example,  if  the  schedule  is  shortened,  often  the  budget  needs  to  be  increased  to  add  additional 
resources  to  complete  the  same  amount  of  work  in  less  time.  If  a budget  increase  is  not  possible,  the  scope  or 
targeted  quality  may  be  reduced  to  deliver  the  project’s  end  result  in  less  time  within  the  same  budget  amount. 
Project  stakeholders  may  have  differing  ideas  as  to  which  factors  are  the  most  important,  creating  an  even  greater 
challenge.  Changing  the  project  requirements  or  objectives  may  create  additional  risks.  The  project  team  needs  to 
be  able  to  assess  the  situation,  balance  the  demands,  and  maintain  proactive  communication  with  stakeholders  in 
order  to  deliver  a successful  project. 

Due  to  the  potential  for  change,  the  development  of  the  project  management  plan  is  an  iterative  activity  and  is 
progressively  elaborated  throughout  the  project’s  life  cycle.  Progressive  elaboration  involves  continuously  improving 
and  detailing  a plan  as  more  detailed  and  specific  information  and  more  accurate  estimates  become  available. 
Progressive  elaboration  allows  a project  management  team  to  define  work  and  manage  it  to  a greater  level  of  detail 
as  the  project  evolves. 
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1.4  Relationships  Among  Portfolio  Management,  Program  Management, 

Project  Management,  and  Organizational  Project  Management  1 

In  order  to  understand  portfolio,  program,  and  project  management,  it  is  important  to  recognize  the  similarities 
and  differences  among  these  disciplines.  It  is  also  helpful  to  understand  how  they  relate  to  organizational  project 
management  (0PM).  0PM  is  a strategy  execution  framework  utilizing  project,  program,  and  portfolio  management 
as  well  as  organizational  enabling  practices  to  consistently  and  predictably  deliver  organizational  strategy  producing 
better  performance,  better  results,  and  a sustainable  competitive  advantage. 

Portfolio,  program,  and  project  management  are  aligned  with  or  driven  by  organizational  strategies.  Conversely, 
portfolio,  program,  and  project  management  differ  in  the  way  each  contributes  to  the  achievement  of  strategic  goals. 

Portfolio  management  aligns  with  organizational  strategies  by  selecting  the  right  programs  or  projects,  prioritizing 
the  work,  and  providing  the  needed  resources,  whereas  program  management  harmonizes  its  projects  and  program 
components  and  controls  interdependencies  in  order  to  realize  specified  benefits.  Project  management  develops 
and  implements  plans  to  achieve  a specific  scope  that  is  driven  by  the  objectives  of  the  program  or  portfolio  it  is 
subjected  to  and,  ultimately,  to  organizational  strategies.  0PM  advances  organizational  capability  by  linking  project, 
program,  and  portfolio  management  principles  and  practices  with  organizational  enablers  (e.g.  structural,  cultural, 
technological,  and  human  resource  practices)  to  support  strategic  goals.  An  organization  measures  its  capabilities, 
then  plans  and  implements  improvements  towards  the  systematic  achievement  of  best  practices. 

Table  1-1  shows  the  comparison  of  project,  program,  and  portfolio  views  across  several  dimensions  within 
the  organization. 
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Table  1-1.  Comparative  Overview  of  Project,  Program,  and  Portfolio  Management 


Organizational  Project  Management 


Projects 

Programs 

Portfolios 

Scope 

Projects  have  defined 
objectives.  Scope  is  progres- 
sively elaborated  throughout  the 
project  life  cycle. 

Programs  have  a larger  scope 
and  provide  more  significant 
benefits. 

Portfolios  have  an  organizational 
scope  that  changes  with  the 
strategic  objectives  of  the 
organization. 

Change 

Project  managers  expect  change 
and  implement  processes  to 
keep  change  managed  and 
controlled. 

Program  managers  expect 
change  from  both  inside  and 
outside  the  program  and  are 
prepared  to  manage  it. 

Portfolio  managers  continuously 
monitor  changes  in  the 
broader  internal  and  external 
environment. 

Planning 

Project  managers  progressively 
elaborate  high-level  information 
into  detailed  plans  throughout 
the  project  life  cycle. 

Program  managers  develop  the 
overall  program  plan  and  create 
high-level  plans  to  guide 
detailed  planning  at  the 
component  level. 

Portfolio  managers  create  and 
maintain  necessary  processes 
and  communication  relative  to 
the  aggregate  portfolio. 

Management 

Project  managers  manage  the 
project  team  to  meet  the  project 
objectives. 

Program  managers  manage  the 
program  staff  and  the  project 
managers;  they  provide  vision 
and  overall  leadership. 

Portfolio  managers  may  manage 
or  coordinate  portfolio 
management  staff,  or  program 
and  project  staff  that  may  have 
reporting  responsibilities  into 
the  aggregate  portfolio. 

Success 

Success  is  measured  by  product 
and  project  quality,  timeliness, 
budget  compliance,  and  degree 
of  customer  satisfaction. 

Success  is  measured  by  the 
degree  to  which  the  program 
satisfies  the  needs  and  benefits 
for  which  it  was  undertaken. 

Success  is  measured  in  terms 
of  the  aggregate  investment 
performance  and  benefit 
realization  of  the  portfolio. 

Monitoring 

Project  managers  monitor  and 
control  the  work  of  producing 
the  products,  services,  or  results 
that  the  project  was  undertaken 
to  produce. 

Program  managers  monitor 
the  progress  of  program 
components  to  ensure  the 
overall  goals,  schedules,  budget, 
and  benefits  of  the  program  will 
be  met. 

Portfolio  managers  monitor 
strategic  changes  and  aggregate 
resource  allocation, 
performance  results,  and  risk 
of  the  portfolio. 
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1.4.1  Program  Management 

A program  is  defined  as  a group  of  related  projects,  subprograms,  and  program  activities  managed  in  a 
coordinated  way  to  obtain  benefits  not  available  from  managing  them  individually.  Programs  may  include  elements 
of  related  work  outside  the  scope  of  the  discrete  projects  in  the  program.  A project  may  or  may  not  be  part  of  a 
program  but  a program  will  always  have  projects. 

Program  management  is  the  application  of  knowledge,  skills,  tools,  and  techniques  to  a program  in  order  to 
meet  the  program  requirements  and  to  obtain  benefits  and  control  not  available  by  managing  projects  individually. 

Projects  within  a program  are  related  through  the  common  outcome  or  collective  capability.  If  the  relationship 
between  projects  is  only  that  of  a shared  client,  seller,  technology,  or  resource,  the  effort  should  be  managed  as  a 
portfolio  of  projects  rather  than  as  a program. 

Program  management  focuses  on  the  project  interdependencies  and  helps  to  determine  the  optimal  approach 
for  managing  them.  Actions  related  to  these  interdependencies  may  include: 

• Resolving  resource  constraints  and/or  conflicts  that  affect  multiple  projects  within  the  program, 

• Aligning  organizational/strategic  direction  that  affects  project  and  program  goals  and  objectives,  and 

• Resolving  issues  and  change  management  within  a shared  governance  structure. 

An  example  of  a program  is  a new  communications  satellite  system  with  projects  for  design  of  the  satellite  and 
the  ground  stations,  the  construction  of  each,  the  integration  of  the  system,  and  the  launch  of  the  satellite. 

1.4.2  Portfolio  Management 

A portfolio  refers  to  projects,  programs,  subportfolios,  and  operations  managed  as  a group  to  achieve  strategic 
objectives.  The  projects  or  programs  of  the  portfolio  may  not  necessarily  be  interdependent  or  directly  related.  For 
example,  an  infrastructure  firm  that  has  the  strategic  objective  of  “maximizing  the  return  on  its  investments”  may 
put  together  a portfolio  that  includes  a mix  of  projects  in  oil  and  gas,  power,  water,  roads,  rail,  and  airports.  From 
this  mix,  the  firm  may  choose  to  manage  related  projects  as  one  program.  All  of  the  power  projects  may  be  grouped 
together  as  a power  program.  Similarly,  all  of  the  water  projects  may  be  grouped  together  as  a water  program. 
Thus,  the  power  program  and  the  water  program  become  integral  components  of  the  enterprise  portfolio  of  the 
infrastructure  firm. 
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Portfolio  management  refers  to  the  centralized  management  of  one  or  more  portfolios  to  achieve  strategic 
objectives.  Portfolio  management  focuses  on  ensuring  that  projects  and  programs  are  reviewed  to  prioritize 
resource  allocation,  and  that  the  management  of  the  portfolio  is  consistent  with  and  aligned  to  organizational 
strategies. 

1 .4.3  Projects  and  Strategic  Planning 

Projects  are  often  utilized  as  a means  of  directly  or  indirectly  achieving  objectives  within  an  organization’s 
strategic  plan.  Projects  are  typically  authorized  as  a result  of  one  or  more  of  the  following  strategic  considerations: 

• Market  demand  (e.g.,  a car  company  authorizing  a project  to  build  more  fuel-efficient  cars  in  response 
to  gasoline  shortages); 

• Strategic  opportunity/business  need  (e.g.,  a training  company  authorizing  a project  to  create  a new 
course  to  increase  its  revenues); 

• Social  need  (e.g.,  a nongovernmental  organization  in  a developing  country  authorizing  a project  to  provide 
potable  water  systems,  latrines,  and  sanitation  education  to  communities  suffering  from  high  rates  of 
infectious  diseases); 

• Environmental  consideration  (e.g.,  a public  company  authorizing  a project  to  create  a new  service  for 
electric  car  sharing  to  reduce  pollution); 

• Customer  request  (e.g.,  an  electric  utility  authorizing  a project  to  build  a new  substation  to  serve  a new 
industrial  park); 

• Technological  advance  (e.g.,  an  electronics  firm  authorizing  a new  project  to  develop  a faster,  cheaper,  and 
smaller  laptop  based  on  advances  in  computer  memory  and  electronics  technology);  and 

• Legal  requirement  (e.g.,  a chemical  manufacturer  authorizing  a project  to  establish  guidelines  for  proper 
handling  of  a new  toxic  material). 

1 .4.4  Project  Management  Office 

A project  management  office  (PMO)  is  a management  structure  that  standardizes  the  project-related  governance 
processes  and  facilitates  the  sharing  of  resources,  methodologies,  tools,  and  techniques.  The  responsibilities  of  a 
PMO  can  range  from  providing  project  management  support  functions  to  actually  being  responsible  for  the  direct 
management  of  one  or  more  projects. 

There  are  several  types  of  PMO  structures  in  organizations,  each  varying  in  the  degree  of  control  and  influence 
they  have  on  projects  within  the  organization,  such  as: 
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• Supportive.  Supportive  PMOs  provide  a consultative  role  to  projects  by  supplying  templates,  best 
practices,  training,  access  to  information  and  lessons  learned  from  other  projects.  This  type  of  PMO 
serves  as  a project  repository.  The  degree  of  control  provided  by  the  PMO  is  low. 

• Controlling.  Controlling  PMOs  provide  support  and  require  compliance  through  various  means. 
Compliance  may  involve  adopting  project  management  frameworks  or  methodologies,  using  specific 
templates,  forms  and  tools,  or  conformance  to  governance.  The  degree  of  control  provided  by  the  PMO 
is  moderate. 

• Directive.  Directive  PMOs  take  control  of  the  projects  by  directly  managing  the  projects.  The  degree  of 
control  provided  by  the  PMO  is  high. 

The  PMO  integrates  data  and  information  from  corporate  strategic  projects  and  evaluates  how  higher  level 
strategic  objectives  are  being  fulfilled.  The  PMO  is  the  natural  liaison  between  the  organization’s  portfolios, 
programs,  projects,  and  the  corporate  measurement  systems  (e.g.  balanced  scorecard). 

The  projects  supported  or  administered  by  the  PMO  may  not  be  related,  other  than  by  being  managed  together. 
The  specific  form,  function,  and  structure  of  a PMO  are  dependent  upon  the  needs  of  the  organization  that  it 
supports. 

A PMO  may  have  the  authority  to  act  as  an  integral  stakeholder  and  a key  decision  maker  throughout  the  life 
of  each  project,  to  make  recommendations,  or  to  terminate  projects  or  take  other  actions,  as  required,  to  remain 
aligned  with  the  business  objectives.  In  addition,  the  PMO  may  be  involved  in  the  selection,  management,  and 
deployment  of  shared  or  dedicated  project  resources. 

A primary  function  of  a PMO  is  to  support  project  managers  in  a variety  of  ways  which  may  include,  but  are  not 
limited  to: 


• Managing  shared  resources  across  all  projects  administered  by  the  PMO; 

• Identifying  and  developing  project  management  methodology,  best  practices,  and  standards; 

• Coaching,  mentoring,  training,  and  oversight; 

• Monitoring  compliance  with  project  management  standards,  policies,  procedures,  and  templates  by  means 
of  project  audits; 

• Developing  and  managing  project  policies,  procedures,  templates,  and  other  shared  documentation 
(organizational  process  assets);  and 

• Coordinating  communication  across  projects. 
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Project  managers  and  PMOs  pursue  different  objectives  and,  as  such,  are  driven  by  different  requirements.  All 
of  these  efforts  are  aligned  with  the  strategic  needs  of  the  organization.  Differences  between  the  role  of  project 
managers  and  a PMO  may  include  the  following: 

• The  project  manager  focuses  on  the  specified  project  objectives,  while  the  PMO  manages  major  program 
scope  changes,  which  may  be  seen  as  potential  opportunities  to  better  achieve  business  objectives. 

• The  project  manager  controls  the  assigned  project  resources  to  best  meet  project  objectives,  while  the 
PMO  optimizes  the  use  of  shared  organizational  resources  across  all  projects. 

• The  project  manager  manages  the  constraints  (scope,  schedule,  cost,  quality,  etc.)  of  the  individual 
projects,  while  the  PMO  manages  the  methodologies,  standards,  overall  risks/opportunities,  metrics,  and 
interdependencies  among  projects  at  the  enterprise  level. 


1.5  Relationship  Between  Project  Management,  Operations  Management, 
and  Organizational  Strategy 

Operations  management  is  responsible  for  overseeing,  directing,  and  controlling  business  operations.  Operations 
evolve  to  support  the  day-to-day  business,  and  are  necessary  to  achieve  strategic  and  tactical  goals  of  the  business. 
Examples  include:  production  operations,  manufacturing  operations,  accounting  operations,  software  support,  and 
maintenance. 

Though  temporary  in  nature,  projects  can  help  achieve  the  organizational  goals  when  they  are  aligned  with  the 
organization’s  strategy.  Organizations  sometimes  change  their  operations,  products,  or  systems  by  creating  strategic 
business  initiatives  that  are  developed  and  implemented  through  projects.  Projects  require  project  management 
activities  and  skill  sets,  while  operations  require  business  process  management,  operations  management  activities, 
and  skill  sets. 

1.5.1  Operations  and  Project  Management 

Changes  in  business  operations  may  be  the  focus  of  a dedicated  project — especially  if  there  are  substantial 
changes  to  business  operations  as  a result  of  a new  product  or  service  delivery.  Ongoing  operations  are  outside  of 
the  scope  of  a project;  however,  there  are  intersecting  points  where  the  two  areas  cross. 

Projects  can  intersect  with  operations  at  various  points  during  the  product  life  cycle,  such  as: 
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• At  each  closeout  phase; 

• When  developing  a new  product,  upgrading  a product,  or  expanding  outputs; 

• While  improving  operations  or  the  product  development  process;  or 

• Until  the  end  of  the  product  life  cycle. 

At  each  point,  deliverables  and  knowledge  are  transferred  between  the  project  and  operations  for  implementation 
of  the  delivered  work.  This  implementation  occurs  through  a transfer  of  project  resources  to  operations  toward  the 
end  of  the  project,  or  through  a transfer  of  operational  resources  to  the  project  at  the  start. 

Operations  are  ongoing  endeavors  that  produce  repetitive  outputs,  with  resources  assigned  to  do  basically  the 
same  set  of  tasks  according  to  the  standards  institutionalized  in  a product  life  cycle.  Unlike  the  ongoing  nature  of 
operations,  projects  are  temporary  endeavors. 

1. 5.1.1  Operations  Management 

Operations  management  is  a subject  area  that  is  outside  the  scope  of  formal  project  management  as  described 
in  this  standard. 

Operations  management  is  an  area  of  management  concerned  with  ongoing  production  of  goods  and/or 
services.  It  involves  ensuring  that  business  operations  continue  efficiently  by  using  the  optimum  resources  needed 
and  meeting  customer  demands.  It  is  concerned  with  managing  processes  that  transform  inputs  (e.g.,  materials, 
components,  energy,  and  labor)  into  outputs  (e.g.,  products,  goods,  and/or  services). 

1 .5.1 .2  Operational  Stakeholders  in  Project  Management 

While  operations  management  is  different  from  project  management  (see  1 .5.1 .1),  the  needs  of  stakeholders 
who  perform  and  conduct  business  operations  are  important  considerations  in  projects  that  will  affect  their  future 
work  and  endeavors.  Project  managers  who  consider  and  appropriately  include  operational  stakeholders  in  all 
phases  of  projects,  gain  insight  and  avoid  unnecessary  issues  that  often  arise  when  their  input  is  overlooked. 

Operational  stakeholders  should  be  engaged  and  their  needs  identified  as  part  of  the  stakeholder  register,  and 
their  influence  (positive  or  negative)  should  be  addressed  as  part  of  the  risk  management  plan. 
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The  following  list  includes  examples  of  operational  stakeholders  (depending  upon  the  business): 

• Plant  operators, 

• Manufacturing  line  supervisors, 

• Help  desk  staff, 

• Production  system  support  analysts, 

• Customer  service  representative, 

• Salespersons, 

• Maintenance  workers, 

• Telephone  sales  personnel, 

• Call  center  personnel, 

• Retail  workers, 

• Line  managers,  and 

• Training  officers. 

1.5.2  Organizations  and  Project  Management 

Organizations  use  governance  to  establish  strategic  direction  and  performance  parameters.  The  strategic 
direction  provides  the  purpose,  expectations,  goals,  and  actions  necessary  to  guide  business  pursuit  and  is  aligned 
with  business  objectives.  Project  management  activities  should  be  aligned  with  top-level  business  direction,  and 
if  there  is  a change,  then  project  objectives  need  to  be  realigned.  In  a project  environment,  changes  to  project 
objectives  affect  project  efficiency  and  success.  When  the  business  alignment  for  a project  is  constant,  the  chance 
for  project  success  greatly  increases  because  the  project  remains  aligned  with  the  strategic  direction  of  the 
organization.  Should  something  change,  projects  should  change  accordingly. 

1. 5.2.1  Project-Based  Organizations 

Project-based  organizations  (PBOs)  refer  to  various  organizational  forms  that  create  temporary  systems 
for  carrying  out  their  work.  PBOs  can  be  created  by  different  types  of  organizations  (i.e.,  functional,  matrix,  or 
projectized  (see  2.1 .3)).  The  use  of  PBOs  may  diminish  the  hierarchy  and  bureaucracy  inside  the  organizations  as 
the  success  of  the  work  is  measured  by  the  final  result  rather  than  by  position  or  politics. 

PBOs  conductthe  majority  of  their  work  as  projects  and/or  provide  project  ratherthan  functional  approaches.  PBOs 
can  refer  to  either  entire  firms  (as  in  telecommunications,  oil  and  gas,  construction,  consultancy,  and  professional 
services)  multi-firm  consortia,  or  networks;  it  is  also  possible  that  some  large  project-based  organizations  have 
functional  support  areas  or  that  the  PBO  is  nested  within  subsidiaries  or  divisions  of  larger  corporations. 
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1 .5.2.2  The  Link  Between  Project  Management  and  Organizational  Governance 

Projects  (and  programs)  are  undertaken  to  achieve  strategic  business  outcomes,  for  which  many  organizations 
now  adopt  formal  organizational  governance  processes  and  procedures.  Organizational  governance  criteria 
can  impose  constraints  on  projects — particularly  if  the  project  delivers  a service  which  will  be  subject  to  strict 
organizational  governance. 

Because  project  success  may  be  judged  on  the  basis  of  how  well  the  resultant  product  or  service  supports 
organizational  governance,  it  is  important  for  the  project  manager  to  be  knowledgeable  about  corporate/ 
organizational  governance  policies  and  procedures  pertaining  to  the  subject  matter  of  the  product  or  service 
(e.g.,  if  an  organization  has  adopted  policies  in  support  of  sustainability  practices  and  the  project  involves 
construction  of  a new  office  building,  the  project  manager  should  be  aware  of  sustainability  requirements  related 
to  building  construction.) 

1. 5.2.3  The  Relationship  Between  Project  Management  and  Organizational  Strategy 

Organizational  strategy  should  provide  guidance  and  direction  to  project  management — especially  when  one 
considers  that  projects  exist  to  support  organizational  strategies.  Often  it  is  the  project  sponsor  or  the  portfolio  or 
program  manager  who  identifies  alignment  or  potential  conflicts  between  organizational  strategies  and  project  goals 
and  then  communicates  these  to  the  project  manager.  If  the  goals  of  a project  are  in  conflict  with  an  established 
organizational  strategy,  it  is  incumbent  upon  the  project  manager  to  document  and  identify  such  conflicts  as  early 
as  possible  in  the  project.  At  times,  the  development  of  an  organizational  strategy  could  be  the  goal  of  a project 
rather  than  a guiding  principle.  In  such  a case,  it  is  important  for  the  project  to  specifically  define  what  constitutes 
an  appropriate  organizational  strategy  that  will  sustain  the  organization. 


1.6  Business  Value 

Business  value  is  a concept  that  is  unique  to  each  organization.  Business  value  is  defined  as  the  entire  value 
of  the  business;  the  total  sum  of  all  tangible  and  intangible  elements.  Examples  of  tangible  elements  include 
monetary  assets,  fixtures,  stockholder  equity,  and  utility.  Examples  of  intangible  elements  include  good  will,  brand 
recognition,  public  benefit,  and  trademarks.  Depending  on  the  organization,  business  value  scope  can  be  short-, 
medium-,  or  long-term.  Value  may  be  created  through  the  effective  management  of  ongoing  operations.  However, 
through  the  effective  use  of  portfolio,  program,  and  project  management,  organizations  will  possess  the  ability  to 
employ  reliable,  established  processes  to  meet  strategic  objectives  and  obtain  greater  business  value  from  their 
project  investments.  While  not  all  organizations  are  business  driven,  all  organizations  conduct  business-related 
activities.  Whether  an  organization  is  a government  agency  or  a nonprofit  organization,  all  organizations  focus  on 
attaining  business  value  for  their  activities. 
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Successful  business  value  realization  begins  with  comprehensive  strategic  planning  and  management. 
Organizational  strategy  can  be  expressed  through  the  organization’s  mission  and  vision,  including  orientation  to 
markets,  competition,  and  other  environmental  factors.  Effective  organizational  strategy  provides  defined  directions 
for  development  and  growth,  in  addition  to  performance  metrics  for  success.  In  order  to  bridge  the  gap  between 
organizational  strategy  and  successful  business  value  realization,  the  use  of  portfolio,  program,  and  project 
management  techniques  is  essential. 

Portfolio  management  aligns  components  (projects,  programs,  or  operations)  to  the  organizational  strategy, 
organized  into  portfolios  or  subportfolios  to  optimize  project  or  program  objectives,  dependencies,  costs,  timelines, 
benefits,  resources,  and  risks.  This  allows  organizations  to  have  an  overall  view  of  how  the  strategic  goals  are 
reflected  in  the  portfolio,  institute  appropriate  governance  management,  and  authorize  human,  financial,  or  material 
resources  to  be  allocated  based  on  expected  performance  and  benefits. 

Using  program  management,  organizations  have  the  ability  to  align  multiple  projects  for  optimized  or  integrated 
costs,  schedule,  effort,  and  benefits.  Program  management  focuses  on  project  interdependencies  and  helps  to 
determine  the  optimal  approach  for  managing  and  realizing  the  desired  benefits. 

With  project  management,  organizations  have  the  ability  to  apply  knowledge,  processes,  skills,  and  tools  and 
techniques  that  enhance  the  likelihood  of  success  over  a wide  range  of  projects.  Project  management  focuses  on 
the  successful  delivery  of  products,  services,  or  results.  Within  programs  and  portfolios,  projects  are  a means  of 
achieving  organizational  strategy  and  objectives. 

Organizations  can  further  facilitate  the  alignment  of  these  portfolio,  program,  and  project  management  activities 
by  strengthening  organizational  enablers  such  as  structural,  cultural,  technological,  and  human  resource  practices. 
By  continuously  conducting  portfolio  strategic  alignment  and  optimization,  performing  business  impact  analyses, 
and  developing  robust  organizational  enablers,  organizations  can  achieve  successful  transitions  within  the  portfolio, 
program,  and  project  domains  and  attain  effective  investment  management  and  business  value  realization. 


1 .7  Role  of  the  Project  Manager 

The  project  manager  is  the  person  assigned  by  the  performing  organization  to  lead  the  team  that  is  responsible 
for  achieving  the  project  objectives.  The  role  of  a project  manager  is  distinct  from  a functional  manager  or  operations 
manager.  Typically  the  functional  manager  is  focused  on  providing  management  oversight  for  a functional  or  a 
business  unit,  and  operations  managers  are  responsible  for  ensuring  that  business  operations  are  efficient. 
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Depending  on  the  organizational  structure,  a project  manager  may  report  to  a functional  manager.  In  other  cases, 
a project  manager  may  be  one  of  several  project  managers  who  report  to  a program  or  portfolio  manager  who  is 
ultimately  responsible  for  enterprise-wide  projects.  In  this  type  of  structure,  the  project  manager  works  closely  with 
the  program  or  portfolio  manager  to  achieve  the  project  objectives  and  to  ensure  the  project  management  plan 
aligns  with  the  overarching  program  plan.  The  project  manager  also  works  closely  and  in  collaboration  with  other 
roles,  such  as  a business  analyst,  quality  assurance  manager,  and  subject  matter  experts. 

1.7.1  Responsibilities  and  Competencies  of  the  Project  Manager 

In  general,  project  managers  have  the  responsibility  to  satisfy  the  needs:  task  needs,  team  needs,  and 
individual  needs.  As  project  management  is  a critical  strategic  discipline,  the  project  manager  becomes  the  link 
between  the  strategy  and  the  team.  Projects  are  essential  to  the  growth  and  survival  of  organizations.  Projects 
create  value  in  the  form  of  improved  business  processes,  are  indispensable  in  the  development  of  new  products 
and  services,  and  make  it  easier  for  companies  to  respond  to  changes  in  the  environment,  competition,  and 
the  marketplace.  The  project  manager’s  role  therefore  becomes  increasingly  strategic.  However,  understanding 
and  applying  the  knowledge,  tools,  and  techniques  that  are  recognized  as  good  practice  are  not  sufficient  for 
effective  project  management.  In  addition  to  any  area-specific  skills  and  general  management  proficiencies 
required  for  the  project,  effective  project  management  requires  that  the  project  manager  possess  the  following 
competencies: 

• Knowledge — Refers  to  what  the  project  manager  knows  about  project  management. 

• Performance — Refers  to  what  the  project  manager  is  able  to  do  or  accomplish  while  applying  his  or  her 
project  management  knowledge. 

• Personal — Refers  to  how  the  project  manager  behaves  when  performing  the  project  or  related  activity. 
Personal  effectiveness  encompasses  attitudes,  core  personality  characteristics,  and  leadership,  which 
provides  the  ability  to  guide  the  project  team  while  achieving  project  objectives  and  balancing  the  project 
constraints. 

1.7.2  Interpersonal  Skills  of  a Project  Manager 

Project  managers  accomplish  work  through  the  project  team  and  other  stakeholders.  Effective  project  managers 
require  a balance  of  ethical,  interpersonal,  and  conceptual  skills  that  help  them  analyze  situations  and  interact 
appropriately.  Appendix  X3  on  Interpersonal  Skills  describes  important  interpersonal  skills,  such  as: 
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• Leadership, 

• Team  building, 

• Motivation, 

• Communication, 

• Influencing, 

• Decision  making, 

• Political  and  cultural  awareness, 

• Negotiation, 

• Trust  building, 

• Conflict  management,  and 

• Coaching. 

1 .8  Project  Management  Body  of  Knowledge 

The  PMBOK®  Guide  contains  the  standard  for  managing  most  projects  most  of  the  time  across  many  types  of 
industries.  The  standard,  included  in  Annex  A1 , describes  the  project  management  processes  used  to  manage  a 
project  toward  a more  successful  outcome. 

This  standard  is  unique  to  the  project  management  field  and  has  interrelationships  to  other  project  management 
disciplines  such  as  program  management  and  portfolio  management. 

Project  management  standards  do  not  address  all  details  of  every  topic.  This  standard  is  limited  to  individual 
projects  and  the  project  management  processes  that  are  generally  recognized  as  good  practice.  Other  standards 
may  be  consulted  for  additional  information  on  the  broader  context  in  which  projects  are  accomplished,  such  as: 

• The  Standard  for  Program  Management  [3]  addresses  the  management  of  programs, 

• The  Standard  for  Portfolio  Management  [4]  addresses  the  management  of  portfolios, 

• Organizational  Project  Management  Maturity  Model  (0PM3@)  [5]  examines  an  enterprise’s  project 
management  process  capabilities. 
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ORGANIZATIONAL  INFLUENCES  AND  PROJECT  LIFE  CYCLE 


Projects  and  project  management  take  place  in  an  environment  that  is  broader  than  that  of  the  project  itself. 
Understanding  this  broader  context  helps  ensure  that  work  is  carried  out  in  alignment  with  the  organization’s 
goals  and  managed  in  accordance  with  the  organization’s  established  practices.  This  section  describes  how 
organizational  influences  affect  the  methods  used  for  staffing,  managing,  and  executing  the  project.  It  discusses 
the  influence  of  stakeholders  on  the  project  and  its  governance,  the  project  team’s  structure  and  membership,  and 
different  approaches  to  the  phasing  and  relationship  of  activities  within  the  project’s  life  cycle.  The  following  major 
sections  are  addressed: 

2.1  Organizational  Influences  on  Project  Management 

2.2  Project  Stakeholders  and  Governance 

2.3  Project  Team 

2.4  Project  Life  Cycle 
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2.1  Organizational  Influences  on  Project  Management 

An  organization’s  culture,  style,  and  structure  influence  how  its  projects  are  performed.  The  organization’s  level 
of  project  management  maturity  and  its  project  management  systems  can  also  influence  the  project.  When  a project 
involves  external  entities  such  as  those  that  are  part  of  a joint  venture  or  partnering  agreement,  the  project  will  be 
influenced  by  more  than  one  organization.  The  following  sections  describe  organizational  characteristics,  factors,  and 
assets  within  an  enterprise  that  are  likely  to  influence  the  project. 

2.1.1  Organizational  Cultures  and  Styles 

Organizations  are  systematic  arrangements  of  entities  (persons  and/or  departments)  aimed  at  accomplishing 
a purpose,  which  may  involve  undertaking  projects.  An  organization’s  culture  and  style  affect  how  it  conducts  projects. 
Cultures  and  styles  are  group  phenomena  known  as  cultural  norms,  which  develop  over  time.  The  norms  include 
established  approaches  to  initiating  and  planning  projects,  the  means  considered  acceptable  for  getting  the  work 
done,  and  recognized  authorities  who  make  or  influence  decisions. 

Organizational  culture  is  shaped  by  the  common  experiences  of  members  of  the  organization  and  most  organizations 
have  developed  unique  cultures  overtime  by  practice  and  common  usage.  Common  experiences  include,  but  are  not 
limited  to: 

• Shared  visions,  mission,  values,  beliefs,  and  expectations; 

• Regulations,  policies,  methods,  and  procedures; 

• Motivation  and  reward  systems; 

• Risk  tolerance; 

• View  of  leadership,  hierarchy,  and  authority  relationships; 

• Code  of  conduct,  work  ethic,  and  work  hours;  and 

• Operating  environments. 
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The  organization’s  culture  is  an  enterprise  environmental  factor,  as  described  in  Section  2.1.5.  Cultures  and 
styles  are  learned  and  shared  and  may  have  a strong  influence  on  a project’s  ability  to  meet  its  objectives.  A 
project  manager  should  therefore  understand  the  different  organizational  styles  and  cultures  that  may  affect  a 
project.  The  project  manager  needs  to  know  which  individuals  in  the  organization  are  the  decision  makers  or 
influencers  and  work  with  them  to  increase  the  probability  of  project  success. 

In  light  of  globalization,  understanding  the  impact  of  cultural  influences  is  critical  in  projects  involving  diverse 
organizations  and  locations  around  the  world.  Culture  becomes  a critical  factor  in  defining  project  success,  and  multi- 
cultural competence  becomes  critical  for  the  project  manager. 

2.1.2  Organizational  Communications 

Project  management  success  in  an  organization  is  highly  dependent  on  an  effective  organizational  communication 
style,  especially  in  the  face  of  globalization  of  the  project  management  profession.  Organizational  communications 
capabilities  have  great  influence  on  how  projects  are  conducted.  As  a consequence,  project  managers  in  distant 
locations  are  able  to  more  effectively  communicate  with  all  relevant  stakeholders  within  the  organizational  structure  to 
facilitate  decision  making.  Stakeholders  and  project  team  members  can  also  use  electronic  communications  (including 
e-mail,  texting,  instant  messaging,  social  media,  video  and  web  conferencing,  and  other  forms  of  electronic  media)  to 
communicate  with  the  project  manager  formally  or  informally. 

2.1.3  Organizational  Structures 

Organizational  structure  is  an  enterprise  environmental  factor,  which  can  affect  the  availability  of  resources  and 
influence  how  projects  are  conducted  (see  also  Section  2.1 .5).  Organizational  structures  range  from  functional  to 
projectized,  with  a variety  of  matrix  structures  in  between.  Table  2-1  shows  key  project-related  characteristics  of  the 
major  types  of  organizational  structures. 
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Table  2-1 . Influence  of  Organizational  Structures  on  Projects 


Organization 

Structure 

Project 

Characteristics'^^ 

Functional 

Matrix 

Projectized 

Weak  Matrix 

Balanced  Matrix 

Strong  Matrix 

Project  Manager's 
Authority 

Little  or  None 

Low 

Low  to 
Moderate 

Moderate 
to  High 

High  to 
Almost  Total 

Resource 

Availability 

Little  or  None 

Low 

Low  to 
Moderate 

Moderate 
to  High 

High  to 
Almost  Total 

Who  manages  the 
project  budget 

Functional 

Manager 

Functional 

Manager 

Mixed 

Project 

Manager 

Project 

Manager 

Project  Manager's 
Role 

Part-time 

Part-time 

Full-time 

Full-time 

Full-time 

Project  Management 
Administrative  Staff 

Part-time 

Part-time 

Part-time 

Full-time 

Full-time 

The  classic  functional  organization,  shown  in  Figure  2-1,  is  a hierarchy  where  each  employee  has  one  clear 
superior.  Staff  members  are  grouped  by  specialty,  such  as  production,  marketing,  engineering,  and  accounting 
at  the  top  level.  Specialties  may  be  further  subdivided  into  focused  functional  units,  such  as  mechanical  and 
electrical  engineering.  Each  department  in  a functional  organization  will  do  its  project  work  independently  of  other 
departments. 


/ 

i 

\ 


\ 

i 

/ 


(Gray  boxes  represent  staff  engaged  in  project  activities) 


Figure  2-1.  Functional  Organization 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  ( PMBOK ® Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


2 - ORGANIZATIONAL  INFLUENCES  AND  PROJECT  LIFE  CYCLE 


Matrix  organizations,  as  shown  in  Figures  2-2  through  2-4,  reflect  a blend  of  functional  and  projectized 
characteristics.  Matrix  organizations  can  be  classified  as  weak,  balanced,  or  strong  depending  on  the  relative  level 
of  power  and  influence  between  functional  and  project  managers.  Weak  matrix  organizations  maintain  many  of  the 
characteristics  of  a functional  organization,  and  the  role  of  the  project  manager  is  more  of  a coordinator  or  expediter. 
A project  expediter  works  as  staff  assistant  and  communications  coordinator.  The  expediter  cannot  personally 
make  or  enforce  decisions.  Project  coordinators  have  power  to  make  some  decisions,  have  some  authority,  and 
report  to  a higher-level  manager.  Strong  matrix  organizations  have  many  of  the  characteristics  of  the  projectized 
organization,  and  have  full-time  project  managers  with  considerable  authority  and  full-time  project  administrative 
staff.  While  the  balanced  matrix  organization  recognizes  the  need  for  a project  manager,  it  does  not  provide  the 
project  manager  with  the  full  authority  over  the  project  and  project  funding.  Table  2-1  provides  additional  details  of 
the  various  matrix  organizational  structures. 


Figure  2-2.  Weak  Matrix  Organization 
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(Gray  boxes  represent  staff  engaged  in  project  activities) 


\ Project 
Coordination 


Figure  2-3.  Balanced  Matrix  Organization 


-I---- 

(Gray  boxes  represent  staff  engaged  in  project  activities)  Project  Coordination 


Figure  2-4.  Strong  Matrix  Organization 
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At  the  opposite  end  of  the  spectrum  to  the  functional  organization  is  the  projectized  organization,  shown  in 
Figure  2-5.  In  a projectized  organization,  team  members  are  often  colocated.  Most  of  the  organization’s  resources 
are  involved  in  project  work,  and  project  managers  have  a great  deal  of  independence  and  authority.  Virtual 
collaboration  techniques  are  often  used  to  accomplish  the  benefits  of  colocated  teams.  Projectized  organizations 
often  have  organizational  units  called  departments,  but  they  can  either  report  directly  to  the  project  manager  or 
provide  support  services  to  the  various  projects. 


Figure  2-5.  Projectized  Organization 


Many  organizations  involve  all  these  structures  at  various  levels,  often  referred  to  as  a composite  organization, 
as  shown  in  Figure  2-6.  For  example,  even  a fundamentally  functional  organization  may  create  a special  project 
team  to  handle  a critical  project.  Such  a team  may  have  many  of  the  characteristics  of  a project  team  in  a projectized 
organization.  The  team  may  include  full-time  staff  from  different  functional  departments,  may  develop  its  own  set 
of  operating  procedures,  and  may  even  operate  outside  of  the  standard,  formalized  reporting  structure  during  the 
project.  Also,  an  organization  may  manage  most  of  its  projects  in  a strong  matrix,  but  allow  small  projects  to  be 
managed  by  functional  departments. 
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(Gray  boxes  represent  staff  engaged  in  project  activities) 


Figure  2-6.  Composite  Organization 

Many  organizational  structures  include  strategic,  middle  management,  and  operational  levels.  The  project 
manager  may  interact  with  all  three  levels  depending  on  factors  such  as: 

• Strategic  importance  of  the  project, 

• Capacity  of  stakeholders  to  exert  influence  on  the  project, 

• Degree  of  project  management  maturity, 

• Project  management  systems,  and 

• Organizational  communications. 

This  interaction  determines  project  characteristics  such  as: 

• Project  manager’s  level  of  authority, 

• Resource  availability  and  management, 

• Entity  controlling  the  project  budget, 

• Project  manager’s  role,  and 

• Project  team  composition. 
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2.1 .4  Organizational  Process  Assets 

Organizational  process  assets  are  the  plans,  processes,  policies,  procedures,  and  knowledge  bases  specific 
to  and  used  by  the  performing  organization.  They  include  any  artifact,  practice,  or  knowledge  from  any  or  all  of 
the  organizations  involved  in  the  project  that  can  be  used  to  perform  or  govern  the  project.  These  process  assets 
include  formal  and  informal  plans,  processes,  policies,  procedures,  and  knowledge  bases,  specific  to  and  used  by  the 
performing  organization.  The  process  assets  also  include  the  organization’s  knowledge  bases  such  as  lessons  learned 
and  historical  information.  Organizational  process  assets  may  include  completed  schedules,  risk  data,  and  earned 
value  data.  Organizational  process  assets  are  inputs  to  most  planning  processes.  Throughout  the  project,  the  project 
team  members  may  update  and  add  to  the  organizational  process  assets  as  necessary.  Organizational  process  assets 
may  be  grouped  into  two  categories:  (1)  processes  and  procedures,  and  (2)  corporate  knowledge  base. 

2.1 .4.1  Processes  and  Procedures 

The  organization’s  processes  and  procedures  for  conducting  project  work  include,  but  are  not  limited  to: 

• Initiating  and  Planning: 

o Guidelines  and  criteria  for  tailoring  the  organization’s  set  of  standard  processes  and  procedures 
to  satisfy  the  specific  needs  of  the  project; 

o Specific  organizational  standards  such  as  policies  (e.g.,  human  resources  policies,  health  and 
safety  policies,  ethics  policies,  and  project  management  policies),  product  and  project  life  cycles, 
and  quality  policies  and  procedures  (e.g.,  process  audits,  improvement  targets,  checklists,  and 
standardized  process  definitions  for  use  in  the  organization);  and 

o Templates  (e.g.,  risk  register,  work  breakdown  structure,  project  schedule  network  diagram,  and 
contract  templates). 

• Executing,  Monitoring  and  Controlling: 

o Change  control  procedures,  including  the  steps  by  which  performing  organization  standards, 
policies,  plans,  and  procedures  or  any  project  documents  will  be  modified,  and  how  any  changes 
will  be  approved  and  validated; 

o Financial  controls  procedures  (e.g.,  time  reporting,  required  expenditure  and  disbursement 
reviews,  accounting  codes,  and  standard  contract  provisions); 

o Issue  and  defect  management  procedures  defining  issue  and  defect  controls,  issue  and  defect 
identification  and  resolution,  and  action  item  tracking; 
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o Organizational  communication  requirements  (e.g.,  specific  communication  technology  available, 
authorized  communication  media,  record  retention  policies,  and  security  requirements); 

o Procedures  for  prioritizing,  approving,  and  issuing  work  authorizations; 

o Risk  control  procedures,  including  risk  categories,  risk  statement  templates,  probability  and 
impact  definitions,  and  probability  and  impact  matrix;  and 

o Standardized  guidelines,  work  instructions,  proposal  evaluation  criteria,  and  performance 
measurement  criteria. 

• Closing: 

o Project  closure  guidelines  or  requirements  (e.g.,  lessons  learned,  final  project  audits,  project 
evaluations,  product  validations,  and  acceptance  criteria). 

2.1 .4.2  Corporate  Knowledge  Base 

The  organizational  knowledge  base  for  storing  and  retrieving  information  includes,  but  is  not  limited  to: 

• Configuration  management  knowledge  bases  containing  the  versions  and  baselines  of  all  performing 
organization  standards,  policies,  procedures,  and  any  project  documents; 

• Financial  databases  containing  information  such  as  labor  hours,  incurred  costs,  budgets,  and  any  project 
cost  overruns; 

• Historical  information  and  lessons  learned  knowledge  bases  (e.g.,  project  records  and  documents, 
all  project  closure  information  and  documentation,  information  regarding  both  the  results  of  previous 
project  selection  decisions  and  previous  project  performance  information,  and  information  from  risk 
management  activities); 

• Issue  and  defect  management  databases  containing  issue  and  defect  status,  control  information,  issue 
and  defect  resolution,  and  action  item  results; 

• Process  measurement  databases  used  to  collect  and  make  available  measurement  data  on  processes 
and  products;  and 

• Project  files  from  previous  projects  (e.g.,  scope,  cost,  schedule,  and  performance  measurement  baselines, 
project  calendars,  project  schedule  network  diagrams,  risk  registers,  planned  response  actions,  and 
defined  risk  impact). 
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2.1 .5  Enterprise  Environmental  Factors 

Enterprise  environmental  factors  refer  to  conditions,  not  under  the  control  of  the  project  team,  that  influence, 
constrain,  or  direct  the  project.  Enterprise  environmental  factors  are  considered  inputs  to  most  planning  processes, 
may  enhance  or  constrain  project  management  options,  and  may  have  a positive  or  negative  influence  on  the 
outcome. 

Enterprise  environmental  factors  vary  widely  in  type  or  nature.  Enterprise  environmental  factors  include,  but  are 
not  limited  to: 

• Organizational  culture,  structure,  and  governance; 

• Geographic  distribution  of  facilities  and  resources; 

• Government  or  industry  standards  (e.g.,  regulatory  agency  regulations,  codes  of  conduct,  product 
standards,  quality  standards,  and  workmanship  standards); 

• Infrastructure  (e.g.,  existing  facilities  and  capital  equipment); 

• Existing  human  resources  (e.g.,  skills,  disciplines,  and  knowledge,  such  as  design,  development,  legal, 
contracting,  and  purchasing); 

• Personnel  administration  (e.g.,  staffing  and  retention  guidelines,  employee  performance  reviews  and 
training  records,  reward  and  overtime  policy,  and  time  tracking); 

• Company  work  authorization  systems; 

• Marketplace  conditions; 

• Stakeholder  risk  tolerances; 

• Political  climate; 

• Organization’s  established  communications  channels; 

• Commercial  databases  (e.g.,  standardized  cost  estimating  data,  industry  risk  study  information,  and  risk 
databases);  and 

• Project  management  information  system  (e.g.,  an  automated  tool,  such  as  a scheduling  software  tool, 
a configuration  management  system,  an  information  collection  and  distribution  system,  or  web  interfaces 
to  other  online  automated  systems). 
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2.2  Project  Stakeholders  and  Governance 

A stakeholder  is  an  individual,  group,  or  organization  who  may  affect,  be  affected  by,  or  perceive  itself  to  be 
affected  by  a decision,  activity,  or  outcome  of  a project.  Stakeholders  may  be  actively  involved  in  the  project  or  have 
interests  that  may  be  positively  or  negatively  affected  by  the  performance  or  completion  of  the  project.  Different 
stakeholders  may  have  competing  expectations  that  might  create  conflicts  within  the  project.  Stakeholders  may 
also  exert  influence  over  the  project,  its  deliverables,  and  the  project  team  in  order  to  achieve  a set  of  outcomes 
that  satisfy  strategic  business  objectives  or  other  needs.  Project  governance — the  alignment  of  the  project  with 
stakeholders’  needs  or  objectives — is  critical  to  the  successful  management  of  stakeholder  engagement  and 
the  achievement  of  organizational  objectives.  Project  governance  enables  organizations  to  consistently  manage 
projects  and  maximize  the  value  of  project  outcomes  and  align  the  projects  with  business  strategy.  It  provides  a 
framework  in  which  the  project  manager  and  sponsors  can  make  decisions  that  satisfy  both  stakeholder  needs 
and  expectations  and  organizational  strategic  objectives  or  address  circumstances  where  these  may  not  be  in 
alignment. 

2.2.1  Project  Stakeholders 

Stakeholders  include  all  members  of  the  project  team  as  well  as  all  interested  entities  that  are  internal  or 
external  to  the  organization.  The  project  team  identifies  internal  and  external,  positive  and  negative,  and  performing 
and  advising  stakeholders  in  order  to  determine  the  project  requirements  and  the  expectations  of  all  parties 
involved.  The  project  manager  should  manage  the  influences  of  these  various  stakeholders  in  relation  to  the  project 
requirements  to  ensure  a successful  outcome.  Figure  2-7  illustrates  the  relationship  between  the  project,  the 
project  team,  and  various  stakeholders. 
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Figure  2-7.  The  Relationship  Between  Stakeholders  and  the  Project 

Stakeholders  have  varying  levels  of  responsibility  and  authority  when  participating  on  a project.  This  level  can 
change  over  the  course  of  the  project’s  life  cycle.  Their  involvement  may  range  from  occasional  contributions  in 
surveys  and  focus  groups  to  full  project  sponsorship  which  includes  providing  financial,  political,  or  other  support. 
Some  stakeholders  may  also  detract  from  the  success  of  the  project,  either  passively  or  actively.  These  stakeholders 
require  the  project  manager’s  attention  throughout  the  project’s  life  cycle,  as  well  as  planning  to  address  any  issues 
they  may  raise. 

Stakeholder  identification  is  a continuous  process  throughoutthe  entire  project  life  cycle.  Identifying  stakeholders, 
understanding  their  relative  degree  of  influence  on  a project,  and  balancing  their  demands,  needs,  and  expectations 
are  critical  to  the  success  of  the  project.  Failure  to  do  so  can  lead  to  delays,  cost  increases,  unexpected  issues, 
and  other  negative  consequences  including  project  cancellation.  An  example  is  late  recognition  that  the  legal 
department  is  a significant  stakeholder,  which  results  in  delays  and  increased  expenses  due  to  legal  requirements 
that  are  required  to  be  met  before  the  project  can  be  completed  or  the  product  scope  is  delivered. 
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Just  as  stakeholders  can  positively  or  adversely  impact  a project’s  objectives,  a project  can  be  perceived  by 
the  stakeholders  as  having  positive  or  negative  results.  For  example,  business  leaders  from  a community  who  will 
benefit  from  an  industrial  expansion  project  will  see  positive  economic  benefits  to  the  community  in  the  form  of 
additional  jobs,  supporting  infrastructure,  and  taxes.  In  the  case  of  stakeholders  with  positive  expectations  for  the 
project,  their  interests  are  best  served  by  making  the  project  successful.  In  contrast,  the  interests  of  negatively 
affected  stakeholders,  such  as  nearby  homeowners  or  small  business  owners  who  may  lose  property,  be  forced 
to  relocate,  or  accept  unwanted  changes  in  the  local  environment,  are  served  by  impeding  the  project’s  progress. 
Overlooking  negative  stakeholder  interests  can  result  in  an  increased  likelihood  of  failures,  delays,  or  other  negative 
consequences  to  the  project. 

An  important  part  of  a project  manager’s  responsibility  is  to  manage  stakeholder  expectations,  which  can  be 
difficult  because  stakeholders  often  have  very  different  or  conflicting  objectives.  Part  of  the  project  manager’s 
responsibility  is  to  balance  these  interests  and  ensure  that  the  project  team  interacts  with  stakeholders  in  a 
professional  and  cooperative  manner.  Project  managers  may  involve  the  project’s  sponsor  or  other  team  members 
from  different  locations  to  identify  and  manage  stakeholders  that  could  be  dispersed  around  the  world. 

The  following  are  some  examples  of  project  stakeholders: 

• Sponsor.  A sponsor  is  the  person  or  group  who  provides  resources  and  support  for  the  project  and  is 
accountable  for  enabling  success.  The  sponsor  may  be  external  or  internal  to  the  project  manager’s 
organization.  From  initial  conception  through  project  closure,  the  sponsor  promotes  the  project.  This 
includes  serving  as  spokesperson  to  higher  levels  of  management  to  gather  support  throughout  the 
organization  and  promoting  the  benefits  the  project  brings.  The  sponsor  leads  the  project  through  the 
initiating  processes  until  formally  authorized,  and  plays  a significant  role  in  the  development  of  the  initial 
scope  and  charter.  For  issues  that  are  beyond  the  control  of  the  project  manager,  the  sponsor  serves 
as  an  escalation  path.  The  sponsor  may  also  be  involved  in  other  important  issues  such  as  authorizing 
changes  in  scope,  phase-end  reviews,  and  go/no-go  decisions  when  risks  are  particularly  high.  The 
sponsor  also  ensures  a smooth  transfer  of  the  project’s  deliverables  into  the  business  of  the  requesting 
organization  after  project  closure. 

• Customers  and  users.  Customers  are  the  persons  or  organizations  who  will  approve  and  manage  the 
project’s  product,  service,  or  result.  Users  are  the  persons  or  organizations  who  will  use  the  project’s 
product,  service,  or  result.  Customers  and  users  may  be  internal  or  external  to  the  performing  organization 
and  may  also  exist  in  multiple  layers.  For  example,  the  customers  for  a new  pharmaceutical  product 
could  include  the  doctors  who  prescribe  it,  the  patients  who  use  it  and  the  insurers  who  pay  for  it.  In  some 
application  areas,  customers  and  users  are  synonymous,  while  in  others,  customers  refer  to  the  entity 
acquiring  the  project’s  product,  and  users  refer  to  those  who  will  directly  utilize  the  project’s  product. 
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• Sellers.  Sellers,  also  called  vendors,  suppliers,  or  contractors,  are  external  companies  that  enter  into  a 
contractual  agreement  to  provide  components  or  services  necessary  for  the  project. 

• Business  partners.  Business  partners  are  external  organizations  that  have  a special  relationship  with 
the  enterprise,  sometimes  attained  through  a certification  process.  Business  partners  provide  specialized 
expertise  or  fill  a specified  role  such  as  installation,  customization,  training,  or  support. 

• Organizational  groups.  Organizational  groups  are  internal  stakeholders  who  are  affected  by  the  activities 
of  the  project  team.  Examples  of  various  business  elements  of  an  organization  that  may  be  affected  by 
the  project  include  marketing  and  sales,  human  resources,  legal,  finance,  operations,  manufacturing,  and 
customer  service.  These  groups  support  the  business  environment  where  projects  are  executed,  and 
are  therefore  affected  by  the  activities  of  the  project.  As  a result,  there  is  generally  a significant  amount 
of  interaction  between  the  various  business  elements  of  an  organization  and  the  project  team  as  they 
work  together  to  achieve  project  goals.  These  groups  may  provide  input  to  requirements  and  accept 
deliverables  necessary  for  a smooth  transition  to  production  or  related  operations. 

• Functional  managers.  Functional  managers  are  key  individuals  who  play  a management  role  within 
an  administrative  or  functional  area  of  the  business,  such  as  human  resources,  finance,  accounting,  or 
procurement.  They  are  assigned  their  own  permanent  staff  to  carry  out  the  ongoing  work,  and  they  have 
a clear  directive  to  manage  all  tasks  within  their  functional  area  of  responsibility.  The  functional  manager 
may  provide  subject  matter  expertise  or  their  function  may  provide  services  to  the  project. 

• Other  stakeholders.  Additional  stakeholders,  such  as  procurement  entities,  financial  institutions, 
government  regulators,  subject  matter  experts,  consultants,  and  others,  may  have  a financial  interest  in 
the  project,  contribute  inputs  to  the  project,  or  have  an  interest  in  the  outcome  of  the  project. 

Project  stakeholders  and  stakeholder  engagement  are  further  defined  in  Section  13  on  Project  Stakeholder 
Management. 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKe‘  Guide)  - Fifth  Edition 


33 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


2 - ORGANIZATIONAL  INFLUENCES  AND  PROJECT  LIFE  CYCLE 


34 


2.2.2  Project  Governance 

Project  governance  is  an  oversight  function  that  is  aligned  with  the  organization’s  governance  model  and  that 
encompasses  the  project  life  cycle.  Project  governance  framework  provides  the  project  manager  and  team  with 
structure,  processes,  decision-making  models  and  tools  for  managing  the  project,  while  supporting  and  controlling 
the  project  for  successful  delivery.  Project  governance  is  a critical  element  of  any  project,  especially  on  complex  and 
risky  projects.  It  provides  a comprehensive,  consistent  method  of  controlling  the  project  and  ensuring  its  success 
by  defining  and  documenting  and  communicating  reliable,  repeatable  project  practices.  It  includes  a framework 
for  making  project  decisions;  defines  roles,  responsibilities,  and  accountabilities  for  the  success  of  the  project;  and 
determines  the  effectiveness  of  the  project  manager.  A project’s  governance  is  defined  by  and  fits  within  the  larger 
context  of  the  portfolio,  program,  or  organization  sponsoring  it  but  is  separate  from  organizational  governance. 

For  project  governance,  the  PMO  may  also  play  some  decisive  role.  Project  governance  involves  stakeholders 
as  well  as  documented  policies,  procedures,  and  standards;  responsibilities;  and  authorities.  Examples  of  the 
elements  of  a project  governance  framework  include: 

• Project  success  and  deliverable  acceptance  criteria; 

• Process  to  identify,  escalate,  and  resolve  issues  that  arise  during  the  project; 

• Relationship  among  the  project  team,  organizational  groups,  and  external  stakeholders; 

• Project  organization  chart  that  identifies  project  roles; 

• Processes  and  procedures  for  the  communication  of  information; 

• Project  decision-making  processes; 

• Guidelines  for  aligning  project  governance  and  organizational  strategy; 

• Project  life  cycle  approach; 

• Process  for  stage  gate  or  phase  reviews; 

• Process  for  review  and  approval  for  changes  to  budget,  scope,  quality,  and  schedule  which  are  beyond 
the  authority  of  the  project  manager;  and 

• Process  to  align  internal  stakeholders  with  project  process  requirements. 
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Within  those  constraints,  as  well  as  the  additional  limitations  of  time  and  budget,  it  is  up  to  the  project  manager 
and  the  project  team  to  determine  the  most  appropriate  method  of  carrying  out  the  project.  While  project  governance 
is  the  framework  in  which  the  project  team  performs,  the  team  is  still  responsible  for  planning,  executing,  controlling, 
and  closing  the  project.  The  project  governance  approach  should  be  described  in  the  project  management  plan. 
Decisions  are  made  regarding  who  will  be  involved,  the  escalation  procedures,  what  resources  are  necessary,  and 
the  general  approach  to  completing  the  work.  Another  important  consideration  is  whether  more  than  one  phase  will 
be  involved  and,  if  so,  the  specific  life  cycle  for  the  individual  project. 


2.2.3  Project  Success 

Since  projects  are  temporary  in  nature,  the  success  of  the  project  should  be  measured  in  terms  of  completing 
the  project  within  the  constraints  of  scope,  time,  cost,  quality,  resources,  and  risk  as  approved  between  the  project 
managers  and  senior  management.  To  ensure  realization  of  benefits  for  the  undertaken  project,  a test  period  (such 
as  soft  launch  in  services)  can  be  part  of  the  total  project  time  before  handing  it  over  to  the  permanent  operations. 
Project  success  should  be  referred  to  the  last  baselines  approved  by  the  authorized  stakeholders. 

The  project  manager  is  responsible  and  accountable  for  setting  realistic  and  achievable  boundaries  for  the 
project  and  to  accomplish  the  project  within  the  approved  baselines. 


2.3  Project  Team 

The  project  team  includes  the  project  manager  and  the  group  of  individuals  who  act  together  in  performing  the 
work  of  the  project  to  achieve  its  objectives.  The  project  team  includes  the  project  manager,  project  management 
staff,  and  other  team  members  who  carry  out  the  work  but  who  are  not  necessarily  involved  with  management  of 
the  project.  This  team  is  comprised  of  individuals  from  different  groups  with  specific  subject  matter  knowledge  or 
with  a specific  skill  set  to  carry  out  the  work  of  the  project.  The  structure  and  characteristics  of  a project  team  can 
vary  widely,  but  one  constant  is  the  project  manager’s  role  as  the  leader  of  the  team,  regardless  of  what  authority 
the  project  manager  may  have  over  its  members. 
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Project  teams  include  roles  such  as: 

• Project  management  staff.  The  members  of  the  team  who  perform  project  management  activities  such 
as  scheduling,  budgeting,  reporting  and  control,  communications,  risk  management  and  administrative 
support.  This  role  may  be  performed  or  supported  by  a project  management  office  (PMO). 

• Project  staff.  The  members  of  the  team  who  carry  out  the  work  of  creating  the  project  deliverables. 

• Supporting  experts.  Supporting  experts  perform  activities  required  to  develop  or  execute  the  project 
management  plan.  These  can  include  such  roles  as  contracting,  financial  management,  logistics,  legal, 
safety,  engineering,  test,  or  quality  control.  Depending  on  the  size  of  the  project  and  level  of  support 
required,  supporting  experts  may  be  assigned  to  work  full  time  or  may  just  participate  on  the  team  when 
their  particular  skills  are  required. 

• User  or  Customer  Representatives.  Members  of  the  organization  who  will  accept  the  deliverables  or 
products  of  the  project  may  be  assigned  to  act  as  representatives  or  liaisons  to  ensure  proper  coordination, 
advise  on  requirements,  or  validate  the  acceptability  of  the  project’s  results. 

• Sellers.  Sellers,  also  called  vendors,  suppliers,  or  contractors,  are  external  companies  that  enter  into 
a contractual  agreement  to  provide  components  or  services  necessary  for  the  project.  The  project  team 
is  often  assigned  the  responsibility  to  oversee  the  performance  and  acceptance  of  sellers’  deliverables 
or  services.  If  the  sellers  bear  a large  share  of  the  risk  for  delivering  the  project’s  results,  they  may  play 
a significant  role  on  the  project  team. 

• Business  partner  members.  Members  of  business  partners’  organizations  may  be  assigned  as  members 
of  the  project  team  to  ensure  proper  coordination. 

• Business  partners.  Business  partners  are  also  external  companies,  but  they  have  a special  relationship 
with  the  enterprise,  sometimes  attained  through  a certification  process.  Business  partners  provide 
specialized  expertise  or  fill  a specified  role  such  as  installation,  customization,  training,  or  support. 
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2.3.1  Composition  of  Project  Teams 

The  composition  of  project  teams  varies  based  on  factors  such  as  organizational  culture,  scope,  and  location. 
The  relationship  between  the  project  manager  and  the  team  varies  depending  on  the  authority  of  the  project 
manager.  In  some  cases,  a project  manager  may  be  the  team’s  line  manager,  with  full  authority  over  its  members. 
In  other  cases,  a project  manager  may  have  little  or  no  direct  organizational  authority  over  the  team  members  and 
may  have  been  brought  in  to  lead  the  project  on  a part-time  basis  or  under  contract.  The  following  are  examples 
of  basic  project  team  compositions: 

• Dedicated.  In  a dedicated  team,  all  or  a majority  of  the  project  team  members  are  assigned  to  work 
full-time  on  the  project.  The  project  team  may  be  colocated  or  virtual  and  usually  reports  directly  to  the 
project  manager.  This  is  the  simplest  structure  for  a project  manager,  as  the  lines  of  authority  are  clear 
and  team  members  can  focus  on  the  project’s  objectives. 

• Part-Time.  Some  projects  are  established  as  temporary  additional  work,  with  the  project  manager  and 
team  members  working  on  the  project  while  remaining  in  their  existing  organizations  and  continuing  to 
carry  out  their  normal  functions.  The  functional  managers  maintain  control  over  the  team  members  and 
the  resources  allocated  to  the  project,  and  the  project  manager  is  likely  to  continue  performing  other 
management  duties.  Part-time  team  members  may  also  be  assigned  to  more  than  one  project  at  a time. 

Dedicated  and  part-time  project  team  compositions  may  exist  in  any  of  the  organizational  structures.  Dedicated 
project  teams  are  often  seen  in  projectized  organizations,  where  most  of  the  organization’s  resources  are  involved 
in  project  work  and  project  managers  have  a great  deal  of  independence  and  authority.  Part-time  project  teams 
are  common  within  functional  organizations,  and  matrix  organizations  use  both  dedicated  and  part-time  project 
teams.  Other  members  who  have  limited  involvement  at  various  stages  of  a project  can  be  thought  of  as  part-time 
project  team  members. 

Project  team  composition  may  also  vary  based  on  organizational  structure.  An  example  of  this  is  a partnership- 
based  project.  A project  may  be  established  as  a partnership,  joint  venture,  consortium,  or  alliance  among  several 
organizations  through  contracts  or  agreements.  In  this  structure,  one  organization  takes  the  lead  and  assigns  a 
project  manager  to  coordinate  the  efforts  among  the  partners.  Partnership-based  projects  can  offer  flexibility  at 
lower  cost.  These  advantages  may  be  offset  by  the  project  manager’s  lower  degree  of  control  over  team  members 
and  the  need  for  strong  mechanisms  for  communication  and  monitoring  progress.  Partnership  projects  may  be  set 
up  to  exploit  industrial  synergies,  to  undertake  ventures  that  one  partner  could  not  afford  alone,  or  for  other  political 
and  strategic  reasons. 
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Project  team  composition  may  also  vary  based  on  the  geographic  location  of  its  members.  An  example  of  this  is 
virtual  project  teams.  Communication  technologies  allow  team  members  in  different  locations  or  countries  to  work 
as  virtual  teams.  Virtual  teams  rely  on  collaborative  tools,  such  as  shared  online  workspaces  and  video  conferences, 
to  coordinate  their  activities  and  exchange  information  about  the  project.  A virtual  team  can  exist  with  any  type 
of  organizational  structure  and  team  composition.  Virtual  teams  are  often  necessary  for  projects  where  resources 
are  located  onsite  or  offsite  or  both,  depending  on  the  project  activities.  A project  manager  who  is  leading  a virtual 
team  needs  to  accommodate  differences  in  the  culture,  working  hours,  time  zones,  local  conditions,  and  languages. 


2.4  Project  Life  Cycle 

A project  life  cycle  is  the  series  of  phases  that  a project  passes  through  from  its  initiation  to  its  closure.  The 
phases  are  generally  sequential,  and  their  names  and  numbers  are  determined  by  the  management  and  control 
needs  of  the  organization  or  organizations  involved  in  the  project,  the  nature  of  the  project  itself,  and  its  area  of 
application.  The  phases  can  be  broken  down  by  functional  or  partial  objectives,  intermediate  results  or  deliverables, 
specific  milestones  within  the  overall  scope  of  work,  or  financial  availability.  Phases  are  generally  time  bounded, 
with  a start  and  ending  or  control  point.  A life  cycle  can  be  documented  within  a methodology.  The  project  life 
cycle  can  be  determined  or  shaped  by  the  unique  aspects  of  the  organization,  industry,  or  technology  employed. 
While  every  project  has  a definite  start  and  a definite  end,  the  specific  deliverables  and  activities  that  take  place 
in  between  will  vary  widely  with  the  project.  The  life  cycle  provides  the  basic  framework  for  managing  the  project, 
regardless  of  the  specific  work  involved. 

Project  life  cycles  can  range  along  a continuum  from  predictive  or  plan-driven  approaches  at  one  end  to  adaptive 
or  change-driven  approaches  at  the  other.  In  a predictive  life  cycle  (Section  2. 4.2. 2),  the  product  and  deliverables 
are  defined  at  the  beginning  of  the  project  and  any  changes  to  scope  are  carefully  managed.  In  an  adaptive  life 
cycle  (Section  2. 4.2. 4),  the  product  is  developed  over  multiple  iterations  and  detailed  scope  is  defined  for  each 
iteration  only  as  the  iteration  begins. 

2.4.1  Characteristics  of  the  Project  Life  Cycle 

Projects  vary  in  size  and  complexity.  All  projects  can  be  mapped  to  the  following  generic  life  cycle  structure  (see 
Figure  2-8): 
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• Starting  the  project, 

• Organizing  and  preparing, 

• Carrying  out  the  project  work,  and 

• Closing  the  project. 

This  generic  life  cycle  structure  is  often  referred  to  when  communicating  with  upper  management  or  other 
entities  less  familiar  with  the  details  of  the  project.  It  should  not  be  confused  with  the  Project  Management  Process 
Groups,  because  the  processes  in  a Process  Group  consist  of  activities  that  may  be  performed  and  recur  within 
each  phase  of  a project  as  well  as  for  the  project  as  a whole.  The  project  life  cycle  is  independent  from  the  life  cycle 
of  the  product  produced  by  or  modified  by  the  project.  However,  the  project  should  take  the  current  life-cycle  phase 
of  the  product  into  consideration.  This  high-level  view  can  provide  a common  frame  of  reference  for  comparing 
projects — even  if  they  are  dissimilar  in  nature. 
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Figure  2-8.  Typical  Cost  and  Staffing  Levels  Across  a Generic  Project  Life  Cycle  Structure 
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The  generic  life  cycle  structure  generally  displays  the  following  characteristics: 

• Cost  and  staffing  levels  are  low  at  the  start,  peak  as  the  work  is  carried  out,  and  drop  rapidly  as  the 
project  draws  to  a close.  Figure  2-8  illustrates  this  typical  pattern. 

• The  typical  cost  and  staffing  curve  above  may  not  apply  to  all  projects.  A project  may  require  significant 
expenditures  to  secure  needed  resources  early  in  its  life  cycle,  for  instance,  or  be  fully  staffed  from  a point 
very  early  in  its  life  cycle. 

• Risk  and  uncertainty  (as  illustrated  in  Figure  2-9)  are  greatest  at  the  start  of  the  project.  These  factors 
decrease  over  the  life  of  the  project  as  decisions  are  reached  and  as  deliverables  are  accepted. 

• The  ability  to  influence  the  final  characteristics  of  the  project’s  product,  without  significantly  impacting 
cost,  is  highest  at  the  start  of  the  project  and  decreases  as  the  project  progresses  towards  completion. 
Figure  2-9  illustrates  the  idea  that  the  cost  of  making  changes  and  correcting  errors  typically  increases 
substantially  as  the  project  approaches  completion. 

While  these  characteristics  remain  present  to  some  extent  in  almost  all  project  life  cycles,  they  are  not  always 
present  to  the  same  degree.  Adaptive  life  cycles,  in  particular,  are  developed  with  the  intent  of  keeping  stakeholder 
influences  higher  and  the  costs  of  changes  lower  throughout  the  life  cycle  than  in  predictive  life  cycles. 


Figure  2-9.  Impact  of  Variable  Based  on  Project  Time 
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Within  the  context  of  the  generic  life  cycle  structure,  a project  manager  may  determine  the  need  for  more 
effective  control  over  certain  deliverables  or  that  certain  deliverables  are  required  to  be  completed  before  the 
project  scope  can  be  completely  defined.  Large  and  complex  projects  in  particular  may  require  this  additional 
level  of  control.  In  such  instances,  the  work  carried  out  to  complete  the  project’s  objective  may  benefit  from  being 
formally  divided  into  phases. 

2.4.2  Project  Phases 

A project  may  be  divided  into  any  number  of  phases.  A project  phase  is  a collection  of  logically  related  project 
activities  that  culminates  in  the  completion  of  one  or  more  deliverables.  Project  phases  are  used  when  the  nature 
of  the  work  to  be  performed  is  unique  to  a portion  of  the  project,  and  are  typically  linked  to  the  development  of 
a specific  major  deliverable.  A phase  may  emphasize  processes  from  a particular  Project  Management  Process 
Group,  but  it  is  likely  that  most  or  all  processes  will  be  executed  in  some  form  in  each  phase.  Project  phases 
typically  are  completed  sequentially,  but  can  overlap  in  some  project  situations.  Different  phases  typically  have  a 
different  duration  or  effort.  The  high-level  nature  of  project  phases  makes  them  an  element  of  the  project  life  cycle. 

The  phase  structure  allows  the  project  to  be  segmented  into  logical  subsets  for  ease  of  management,  planning, 
and  control.  The  number  of  phases,  the  need  for  phases,  and  the  degree  of  control  applied  depend  on  the  size, 
complexity,  and  potential  impact  of  the  project.  Regardless  of  the  number  of  phases  comprising  a project,  all 
phases  have  similar  characteristics: 

• The  work  has  a distinct  focus  that  differs  from  any  other  phase.  This  often  involves  different  organizations, 
locations,  and  skill  sets. 

• Achieving  the  primary  deliverable  or  objective  of  the  phase  requires  controls  or  processes  unique  to  the 
phase  or  its  activities.  The  repetition  of  processes  across  all  five  Process  Groups,  as  described  in  Section 
3,  provides  an  additional  degree  of  control  and  defines  the  boundaries  of  the  phase. 

• The  closure  of  a phase  ends  with  some  form  of  transfer  or  hand-off  of  the  work  product  produced  as  the 
phase  deliverable.  This  phase  end  represents  a natural  point  to  reassess  the  activities  underway  and  to 
change  or  terminate  the  project  if  necessary.  This  point  may  be  referred  to  as  a stage  gate,  milestone, 
phase  review,  phase  gate  or  kill  point.  In  many  cases,  the  closure  of  a phase  is  required  to  be  approved 
in  some  form  before  it  can  be  considered  closed. 
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There  is  no  single  ideal  structure  that  will  apply  to  all  projects.  Although  industry  common  practices  will  often 
lead  to  the  use  of  a preferred  structure,  projects  in  the  same  industry — or  even  in  the  same  organization — may 
have  significant  variation.  Some  will  have  only  one  phase,  as  shown  in  Figure  2-10.  Other  projects  may  have  two 
or  more  phases. 


One  Approach  to  Managing  the  Installation  of  a Telecommunications  Network 


Monitoring  and  Controlling  Processes 


Figure  2-10.  Example  of  a Single-Phase  Project 

Some  organizations  have  established  policies  that  standardize  all  projects,  while  others  allow  the  project  team 
to  choose  and  tailor  the  most  appropriate  approach  for  their  individual  project.  For  instance,  one  organization 
may  treat  a feasibility  study  as  routine  pre-project  work,  another  may  treat  it  as  the  first  phase  of  a project,  and 
a third  may  treat  the  feasibility  study  as  a separate,  stand-alone  project.  Likewise,  one  project  team  may  divide  a 
project  into  two  phases  whereas  another  project  team  may  choose  to  manage  all  the  work  as  a single  phase.  Much 
depends  on  the  nature  of  the  specific  project  and  the  style  of  the  project  team  or  organization. 

2.4.2.1  Phase-to-Phase  Relationships 

When  projects  have  more  than  one  phase,  the  phases  are  part  of  a generally  sequential  process  designed  to 
ensure  proper  control  of  the  project  and  attain  the  desired  product,  service,  or  result.  Flowever,  there  are  situations 
when  a project  might  benefit  from  overlapping  or  concurrent  phases. 

There  are  two  basic  types  of  phase-to-phase  relationships: 

• Sequential  relationship.  In  a sequential  relationship,  a phase  starts  only  when  the  previous  phase  is 
complete.  Figure  2-11  shows  an  example  of  a project  with  three  entirely  sequential  phases.  The  step- 
by-step  nature  of  this  approach  reduces  uncertainty,  but  may  eliminate  options  for  reducing  the  overall 
schedule. 
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One  Approach  to  Cleaning  Up  a Hazardous  Waste  Site 
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Figure  2-11.  Example  of  a Three-Phase  Project 

• Overlapping  relationship.  In  an  overlapping  relationship,  a phase  starts  priorto  completion  of  the  previous 
one  (see  Figure  2-12).  This  can  sometimes  be  applied  as  an  example  of  the  schedule  compression 
technique  called  fast  tracking.  Overlapping  phases  may  require  additional  resources  to  allow  work  to  be 
done  in  parallel,  may  increase  risk,  and  can  result  in  rework  if  a subsequent  phase  progresses  before 
accurate  information  is  available  from  the  previous  phase. 


Potential  Approach  to  Building  a New  Factory 


Figure  2-12.  Example  of  a Project  with  Overlapping  Phases 
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For  projects  with  more  than  one  phase,  there  may  be  different  relationships  (overlapping,  sequential,  parallel) 
between  individual  phases.  Considerations  such  as  level  of  control  required,  effectiveness,  and  degree  of  uncertainty 
determine  the  relationship  to  be  applied  between  phases.  Based  on  those  considerations,  both  relationships  could 
occur  between  different  phases  of  a single  project. 

2A.2.2  Predictive  Life  Cycles 

Predictive  life  cycles  (also  known  as  fully  plan-driven)  are  ones  in  which  the  project  scope,  and  the  time  and 
cost  required  to  deliver  that  scope,  are  determined  as  early  in  the  project  life  cycle  as  practically  possible.  As  shown 
in  Figure  2-13,  these  projects  proceed  through  a series  of  sequential  or  overlapping  phases,  with  each  phase 
generally  focusing  on  a subset  of  project  activities  and  project  management  processes.  The  work  performed  in 
each  phase  is  usually  different  in  nature  to  that  in  the  preceding  and  subsequent  phases,  therefore,  the  makeup 
and  skills  required  of  the  project  team  may  vary  from  phase  to  phase. 


Figure  2-13.  Example  of  Predictive  Life  Cycle 
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When  the  project  is  initiated,  the  project  team  will  focus  on  defining  the  overall  scope  for  the  product  and 
project,  develop  a plan  to  deliver  the  product  (and  any  associated  deliverables),  and  then  proceed  through  phases 
to  execute  the  plan  within  that  scope.  Changes  to  the  project  scope  are  carefully  managed  and  require  re  planning 
and  formal  acceptance  of  the  new  scope.  2 

Predictive  life  cycles  are  generally  preferred  when  the  product  to  be  delivered  is  well  understood,  there  is 
a substantial  base  of  industry  practice,  or  where  a product  is  required  to  be  delivered  in  full  to  have  value  to 
stakeholder  groups. 

Even  projects  with  predictive  life  cycles  may  use  the  concept  of  rolling  wave  planning,  where  a more  general, 
high-level  plan  is  available  and  more  detailed  planning  is  executed  for  appropriate  time  windows,  as  new  work 
activities  are  approaching  and  resources  are  to  be  assigned. 

2.4.2.3  Iterative  and  Incremental  Life  Cycles 

Iterative  and  incremental  life  cycles  are  ones  in  which  project  phases  (also  called  iterations)  intentionally  repeat 
one  or  more  project  activities  as  the  project  team’s  understanding  of  the  product  increases.  Iterations  develop  the 
product  through  a series  of  repeated  cycles,  while  increments  successively  add  to  the  functionality  of  the  product. 

These  life  cycles  develop  the  product  both  iteratively  and  incrementally. 

Iterative  and  incremental  projects  may  proceed  in  phases,  and  the  iterations  themselves  will  be  performed  in  a 
sequential  or  overlapping  fashion.  During  an  iteration,  activities  from  all  Project  Management  Process  Groups  will 
be  performed.  At  the  end  of  each  iteration,  a deliverable  or  set  of  deliverables  will  be  completed.  Future  iterations 
may  enhance  those  deliverables  or  create  new  ones.  Each  iteration  incrementally  builds  the  deliverables  until  the 
exit  criteria  for  the  phase  are  met,  allowing  the  project  team  to  incorporate  feedback. 

In  most  iterative  life  cycles,  a high-level  vision  will  be  developed  for  the  overall  undertaking,  but  the  detailed 
scope  is  elaborated  one  iteration  at  a time.  Often  the  planning  for  the  next  iteration  is  carried  out  as  work  progresses 
on  the  current  iteration’s  scope  and  deliverables.  The  work  required  for  a given  set  of  deliverables  may  vary  in 
duration  and  effort,  and  the  project  team  may  change  between  or  during  iterations.  Those  deliverables  that  are  not 
addressed  within  the  scope  of  the  current  iteration  are  typically  scoped  at  a high  level  only  and  may  be  tentatively 
assigned  to  a specific  future  iteration.  Changes  to  the  scope  of  an  iteration  are  carefully  managed  once  work  begins. 
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Iterative  and  incremental  life  cycles  are  generally  preferred  when  an  organization  needs  to  manage  changing 
objectives  and  scope,  to  reduce  the  complexity  of  a project,  or  when  the  partial  delivery  of  a product  is  beneficial 
and  provides  value  for  one  or  more  stakeholder  groups  without  impact  to  the  final  deliverable  or  set  of  deliverables. 
Large  and  complex  projects  are  frequently  executed  in  an  iterative  fashion  to  reduce  risk  by  allowing  the  team  to 
incorporate  feedback  and  lessons  learned  between  iterations. 

2.4.2A  Adaptive  Life  Cycles 

Adaptive  life  cycles  (also  known  as  change-driven  or  agile  methods)  are  intended  to  respond  to  high  levels 
of  change  and  ongoing  stakeholder  involvement.  Adaptive  methods  are  also  iterative  and  incremental,  but  differ 
in  that  iterations  are  very  rapid  (usually  with  a duration  of  2 to  4 weeks)  and  are  fixed  in  time  and  cost.  Adaptive 
projects  generally  perform  several  processes  in  each  iteration,  although  early  iterations  may  concentrate  more  on 
planning  activities. 

The  overall  scope  of  the  project  will  be  decomposed  into  a set  of  requirements  and  work  to  be  performed, 
sometimes  referred  to  as  a product  backlog.  At  the  beginning  of  an  iteration,  the  team  will  work  to  determine 
how  many  of  the  highest  priority  items  on  the  backlog  list  can  be  delivered  within  the  next  iteration.  At  the  end  of 
each  iteration,  the  product  should  be  ready  for  review  by  the  customer.  This  does  not  mean  that  the  customer  is 
required  to  accept  delivery,  just  that  the  product  should  not  include  unfinished,  incomplete,  or  unusable  features. 
The  sponsor  and  customer  representatives  should  be  continuously  engaged  with  the  project  to  provide  feedback 
on  deliverables  as  they  are  created  and  to  ensure  that  the  product  backlog  reflects  their  current  needs. 

Adaptive  methods  are  generally  preferred  when  dealing  with  a rapidly  changing  environment,  when  requirements 
and  scope  are  difficult  to  define  in  advance,  and  when  it  is  possible  to  define  small  incremental  improvements  that 
will  deliver  value  to  stakeholders. 
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PROJECT  MANAGEMENT  PROCESSES 


Project  management  is  the  application  of  knowledge,  skills,  tools,  and  techniques  to  project  activities  to  meet  the 
project  requirements.  This  application  of  knowledge  requires  the  effective  management  of  the  project  management 
processes. 

A process  is  a set  of  interrelated  actions  and  activities  performed  to  create  a pre-specified  product,  service,  or 
result.  Each  process  is  characterized  by  its  inputs,  the  tools  and  techniques  that  can  be  applied,  and  the  resulting 
outputs.  As  explained  in  Section  2,  the  project  manager  needs  to  consider  organizational  process  assets  and 
enterprise  environmental  factors.  These  should  be  taken  into  account  for  every  process,  even  if  they  are  not 
explicitly  listed  as  inputs  in  the  process  specification.  Organizational  process  assets  provide  guidelines  and  criteria 
for  tailoring  the  organization’s  processes  to  the  specific  needs  of  the  project.  Enterprise  environmental  factors  may 
constrain  the  project  management  options. 

In  order  for  a project  to  be  successful,  the  project  team  should: 

• Select  appropriate  processes  required  to  meet  the  project  objectives; 

• Use  a defined  approach  that  can  be  adapted  to  meet  requirements; 

• Establish  and  maintain  appropriate  communication  and  engagement  with  stakeholders; 

• Comply  with  requirements  to  meet  stakeholder  needs  and  expectations;  and 

• Balance  the  competing  constraints  of  scope,  schedule,  budget,  quality,  resources,  and  risk  to  produce  the 
specified  product,  service,  or  result. 

The  project  processes  are  performed  by  the  project  team  with  stakeholder  interaction  and  generally  fall  into  one 
of  two  major  categories: 

• Project  management  processes.  These  processes  ensure  the  effective  flow  of  the  project  throughout 
its  life  cycle.  These  processes  encompass  the  tools  and  techniques  involved  in  applying  the  skills  and 
capabilities  described  in  the  Knowledge  Areas  (Sections  4 through  1 3). 

• Product-oriented  processes.  These  processes  specify  and  create  the  project’s  product.  Product- 
oriented  processes  are  typically  defined  by  the  project  life  cycle  (as  discussed  in  Section  2.4)  and  vary 
by  application  area  as  well  as  the  phase  of  the  product  life  cycle.  The  scope  of  the  project  cannot  be 
defined  without  some  basic  understanding  of  how  to  create  the  specified  product.  For  example,  various 
construction  techniques  and  tools  need  to  be  considered  when  determining  the  overall  complexity  of  the 
house  to  be  built. 
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The  PMBOK®  Guide  describes  only  the  project  management  processes.  Although  product-oriented  processes 
are  outside  the  scope  of  this  document,  they  should  not  be  ignored  by  the  project  manager  and  project  team.  Project 
management  processes  and  product-oriented  processes  overlap  and  interact  throughout  the  life  of  a project. 

Project  management  processes  apply  globally  and  across  industry  groups.  Good  practice  means  there  is  general 
agreement  that  the  application  of  project  management  processes  has  been  shown  to  enhance  the  chances  of 
success  over  a wide  range  of  projects.  Good  practice  does  not  mean  that  the  knowledge,  skills,  and  processes 
described  should  always  be  applied  uniformly  on  all  projects.  For  any  given  project,  the  project  manager,  in 
collaboration  with  the  project  team,  is  always  responsible  for  determining  which  processes  are  appropriate,  and 
the  appropriate  degree  of  rigor  for  each  process. 

Project  managers  and  their  teams  should  carefully  address  each  process  and  its  inputs  and  outputs  and 
determine  which  are  applicable  to  the  project  they  are  working  on.  The  PMBOK ® Guide  may  be  used  as  a resource 
in  managing  a project  while  considering  the  overall  approach  and  methodology  to  be  followed  for  the  project.  This 
effort  is  known  as  tailoring. 

Project  management  is  an  integrative  undertaking  that  requires  each  project  and  product  process  to  be 
appropriately  aligned  and  connected  with  the  other  processes  to  facilitate  coordination.  Actions  taken  during  one 
process  typically  affect  that  process  and  other  related  processes.  For  example,  a scope  change  typically  affects 
project  cost,  but  it  may  not  affect  the  communications  management  plan  or  level  of  risk.  These  process  interactions 
often  require  tradeoffs  among  project  requirements  and  objectives,  and  the  specific  performance  tradeoffs  will  vary 
from  projectto  project  and  organization  to  organization.  Successful  project  management  includes  actively  managing 
these  interactions  to  meet  sponsor,  customer,  and  other  stakeholder  requirements.  In  some  circumstances,  a 
process  or  set  of  processes  will  need  to  be  iterated  several  times  in  order  to  achieve  the  required  outcome. 

Projects  exist  within  an  organization  and  do  not  operate  as  a closed  system.  They  require  input  data  from  the 
organization  and  beyond,  and  deliver  capabilities  back  to  the  organization.  The  project  processes  may  generate 
information  to  improve  the  management  of  future  projects  and  organizational  process  assets. 

The  PMBOK®  Guide  describes  the  nature  of  project  management  processes  in  terms  of  the  integration  between 
the  processes,  their  interactions,  and  the  purposes  they  serve.  Project  management  processes  are  grouped  into  five 
categories  known  as  Project  Management  Process  Groups  (or  Process  Groups): 
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• Initiating  Process  Group.  Those  processes  performed  to  define  a new  project  or  a new  phase  of  an 
existing  project  by  obtaining  authorization  to  start  the  project  or  phase. 

• Planning  Process  Group.  Those  processes  required  to  establish  the  scope  of  the  project,  refine  the 
objectives,  and  define  the  course  of  action  required  to  attain  the  objectives  that  the  project  was  undertaken 
to  achieve. 

• Executing  Process  Group.  Those  processes  performed  to  complete  the  work  defined  in  the  project 
management  plan  to  satisfy  the  project  specifications. 

• Monitoring  and  Controlling  Process  Group.  Those  processes  required  to  track,  review,  and  regulate  the 
progress  and  performance  of  the  project;  identify  any  areas  in  which  changes  to  the  plan  are  required; 
and  initiate  the  corresponding  changes. 

• Closing  Process  Group.  Those  processes  performed  to  finalize  all  activities  across  all  Process  Groups  to 
formally  close  the  project  or  phase. 

The  remainder  of  this  section  provides  information  for  project  management  of  a single  project  organized  as 
a network  of  interlinked  processes,  details  the  project  management  processes,  and  includes  the  following  major 
sections: 

3.1  Common  Project  Management  Process  Interactions 

3.2  Project  Management  Process  Groups 

3.3  Initiating  Process  Group 

3.4  Planning  Process  Group 

3.5  Executing  Process  Group 

3.6  Monitoring  and  Controlling  Process  Group 

3.7  Closing  Process  Group 

3.8  Project  Information 

3.9  Role  of  the  Knowledge  Areas 

3.10  The  Standard  for  Project  Management  of  a Project 
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3.1  Common  Project  Management  Process  Interactions 

The  project  management  processes  are  presented  as  discrete  elements  with  well-defined  interfaces.  However, 
in  practice  they  overlap  and  interact  in  ways  that  are  not  completely  detailed  in  this  document.  Most  experienced 
project  management  practitioners  recognize  there  is  more  than  one  way  to  manage  a project.  The  required  Process 
Groups  and  their  processes  are  guides  for  applying  appropriate  project  management  knowledge  and  skills  during 
the  project.  The  application  of  the  project  management  processes  is  iterative,  and  many  processes  are  repeated 
during  the  project. 

The  integrative  nature  of  project  management  requires  the  Monitoring  and  Controlling  Process  Group  to  interact 
with  the  other  Process  Groups,  as  shown  in  Figure  3-1.  Monitoring  and  Controlling  processes  occur  at  the  same 
time  as  processes  contained  within  other  Process  Groups.  Thus,  the  Monitoring  and  Controlling  Process  is  pictured 
as  a “background”  Process  Group  for  the  other  four  Process  Groups  shown  in  Figure  3-1. 


Figure  3-1 . Project  Management  Process  Groups 
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Project  Management  Process  Groups  are  linked  by  the  outputs  which  are  produced.  The  Process  Groups  are 
seldom  either  discrete  or  one-time  events;  they  are  overlapping  activities  that  occur  throughout  the  project.  The 
output  of  one  process  generally  becomes  an  input  to  another  process  or  is  a deliverable  of  the  project,  subproject,  or 
project  phase.  Deliverables  at  the  subproject  or  project  level  may  be  called  incremental  deliverables.  The  Planning 
Process  Group  provides  the  Executing  Process  Group  with  the  project  management  plan  and  project  documents, 
and,  as  the  project  progresses,  it  often  creates  updates  to  the  project  management  plan  and  the  project  documents. 
Figure  3-2  illustrates  how  the  Process  Groups  interact  and  shows  the  level  of  overlap  at  various  times.  If  the  project 
is  divided  into  phases,  the  Process  Groups  interact  within  each  phase. 


Initiating 

Process 

Group 


Planning 

Process 

Group 


Executing 

Process 

Group 


Monitoring 
and  Controlling 
Process  Group 


Closing 

Process 

Group 


Level  of 
Process 
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Figure  3-2.  Process  Groups  Interact  in  a Phase  or  Project 

An  example  of  this  interaction  is  the  exit  of  a design  phase,  which  requires  sponsor  acceptance  of  the  design 
document.  Once  it  is  available,  the  design  document  provides  the  product  description  for  the  Planning  and  Executing 
Process  Groups  in  one  or  more  subsequent  phases.  When  a project  is  divided  into  phases,  the  Process  Groups  are 
used,  as  appropriate,  to  effectively  drive  the  project  to  completion  in  a controlled  manner.  In  multiphase  projects, 
processes  are  repeated  within  each  phase  until  the  criteria  for  phase  completion  have  been  satisfied.  Additional 
information  on  project  organization,  life  cycles,  and  project  phases  is  provided  in  Section  2. 
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3.2  Project  Management  Process  Groups 

The  following  sections  identify  and  describe  the  five  Project  Management  Process  Groups  required  for  any 
project.  These  five  Process  Groups  have  clear  dependencies  and  are  typically  performed  in  each  project  and 
highly  interact  with  one  another.  These  five  Process  Groups  are  independent  of  application  areas  or  industry  focus. 
Individual  Process  Groups  and  individual  processes  are  often  iterated  prior  to  completing  the  project  and  can  have 
interactions  within  a Process  Group  and  among  Process  Groups.  The  nature  of  these  interactions  varies  from  project 
to  project  and  may  or  may  not  be  performed  in  a particular  order. 

The  process  flow  diagram,  Figure  3-3,  provides  an  overall  summary  of  the  basic  flow  and  interactions 
among  Process  Groups  and  specific  stakeholders.  The  project  management  processes  are  linked  by  specific 
inputs  and  outputs  where  the  result  or  outcome  of  one  process  becomes  the  input  to  another  process  but  not 
necessarily  in  the  same  Process  Group.  The  Process  Groups  are  not  project  life  cycle  phases.  In  fact,  it  is 
possible  that  all  Process  Groups  could  be  conducted  within  a phase.  As  projects  are  separated  into  distinct  phases 
or  subcomponents,  such  as  concept  development  feasibility  study,  design,  prototype,  build,  or  test,  etc.,  all  of  the 
Process  Groups  would  normally  be  repeated  for  each  phase  or  subcomponent  along  the  lines  explained  previously 
and  illustrated  in  Figure  3-2. 

The  project  management  processes  are  shown  in  the  Process  Group  in  which  most  of  the  related  activities  takes 
place.  For  example,  a process  that  normally  takes  place  in  the  planning  phase  is  put  into  the  Planning  Process 
Group.  When  this  process  is  updated  by  an  Executing  Process  Group  process  or  activity,  it  is  not  considered  a new 
process  within  the  Executing  Process  Group  but  is  still  a Planning  Process  Group  process  or  activity.  The  iterative 
nature  of  project  management  means  that  processes  from  any  group  may  be  reused  throughout  the  project  life 
cycle.  For  example,  in  response  to  a risk  event,  executing  a risk  response  may  trigger  further  analysis,  which  leads 
to  another  iteration  of  the  Identify  Risks  process  and  the  associated  Perform  Quantitative  Risk  Analysis  and  Perform 
Quantitative  Risk  Analysis  processes  to  evaluate  the  impact. 
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* Project  statement  of  work 


• Procurement  documentation 


NOTE:  The  darker  dotted  lines  represent  relationships  between  Process  Groups;  the  lighter  dotted  lines  are  external  to  the  Process  Groups. 


Figure  3-3.  Project  Management  Process  Interactions 
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3.3  Initiating  Process  Group 

The  Initiating  Process  Group  consists  of  those  processes  performed  to  define  a new  project  or  a new  phase 
of  an  existing  project  by  obtaining  authorization  to  start  the  project  or  phase.  Within  the  Initiating  processes,  the 
initial  scope  is  defined  and  initial  financial  resources  are  committed.  Internal  and  external  stakeholders  who 
will  interact  and  influence  the  overall  outcome  of  the  project  are  identified.  If  not  already  assigned,  the  project 
manager  will  be  selected.  This  information  is  captured  in  the  project  charter  and  stakeholder  register.  When  the 
project  charter  is  approved,  the  project  becomes  officially  authorized.  Although  the  project  management  team  may 
help  write  the  project  charter,  this  standard  assumes  that  business  case  assessment,  approval,  and  funding  are 
handled  externally  to  the  project  boundaries  (Figure  3-4).  A project  boundary  is  defined  as  the  point  in  time  that 
a project  or  project  phase  is  authorized  to  its  completion.  The  key  purpose  of  this  Process  Group  is  to  align  the 
stakeholders’  expectations  with  the  project’s  purpose,  give  them  visibility  about  the  scope  and  objectives,  show 
how  their  participation  in  the  project  and  it  associated  phases  can  ensure  that  their  expectations  are  achieved. 
These  processes  help  set  the  vision  of  the  project — what  is  needed  to  be  accomplished. 


Figure  3-4.  Project  Boundaries 

Large  complex  projects  should  be  divided  into  separate  phases.  In  such  projects,  the  Initiating  processes  are 
carried  out  during  subsequent  phases  to  validate  the  decisions  made  during  the  original  Develop  Project  Charter 
and  Identify  Stakeholders  processes.  Performing  the  Initiating  processes  at  the  start  of  each  phase  helps  to  keep 
the  project  focused  on  the  business  need  that  the  project  was  undertaken  to  address.  The  success  criteria  are 
verified,  and  the  influence,  drivers  and  objectives  of  the  project  stakeholders  are  reviewed.  A decision  is  then 
made  as  to  whether  the  project  should  be  continued,  delayed,  or  discontinued. 
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Involving  the  sponsors,  customers,  and  other  stakeholders  during  initiation  creates  a shared  understanding  of 
success  criteria,  reduces  the  overhead  of  involvement,  and  generally  improves  deliverable  acceptance,  customer 
satisfaction,  and  other  stakeholder  satisfaction. 

Initiating  processes  may  be  performed  at  the  organizational,  program,  or  portfolio  level  and  therefore,  would 
be  outside  of  the  project’s  level  of  control.  For  example,  prior  to  commencing  a project,  the  need  for  high-level 
requirements  may  be  documented  as  part  of  a larger  organizational  initiative.  A process  of  evaluating  alternatives 
may  be  utilized  to  determine  the  feasibility  of  the  new  undertaking.  Clear  descriptions  of  the  project  objectives  may 
be  developed,  including  the  reasons  why  a specific  project  is  the  best  alternative  to  satisfy  the  requirements.  The 
documentation  for  this  decision  may  also  contain  the  initial  project  scope  statement,  deliverables,  project  duration, 
and  a forecast  of  the  resources  for  the  organization’s  investment  analysis.  As  part  of  the  Initiating  processes,  the 
project  manager  is  given  the  authority  to  apply  organizational  resources  to  the  subsequent  project  activities. 


3.4  Planning  Process  Group 

The  Planning  Process  Group  consists  of  those  processes  performed  to  establish  the  total  scope  of  the  effort, 
define  and  refine  the  objectives,  and  develop  the  course  of  action  required  to  attain  those  objectives.  The  Planning 
processes  develop  the  project  management  plan  and  the  project  documents  that  will  be  used  to  carry  out  the 
project.  The  complex  nature  of  project  management  may  require  the  use  of  repeated  feedback  loops  for  additional 
analysis.  As  more  project  information  or  characteristics  are  gathered  and  understood,  additional  planning  will 
likely  be  required.  Significant  changes  occurring  throughout  the  project  life  cycle  trigger  a need  to  revisit  one 
or  more  of  the  planning  processes  and  possibly  some  of  the  initiating  processes.  This  progressive  detailing  of 
the  project  management  plan  is  called  progressive  elaboration,  indicating  that  planning  and  documentation  are 
iterative  and  ongoing  activities.  The  key  benefit  of  this  Process  Group  is  to  delineate  the  strategy  and  tactics  as 
well  as  the  course  of  action  or  path  to  successfully  complete  the  project  or  phase.  When  the  Planning  Process 
Group  is  well  managed,  it  is  much  easier  to  get  stakeholder  buy-in  and  engagement.  These  processes  express 
how  this  will  be  done,  setting  the  route  to  the  desired  objective. 

The  project  management  plan  and  project  documents  developed  as  outputs  from  the  Planning  Process  Group 
will  explore  all  aspects  of  the  scope,  time,  cost,  quality,  communications,  human  resources,  risks,  procurements, 
and  stakeholder  engagement. 
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Updates  arising  from  approved  changes  during  the  project  (generally  during  Monitoring  and  Controlling 
processes  and  specifically  during  the  Direct  and  Manage  Project  Work  Process)  may  significantly  impact  parts  of 
the  project  management  plan  and  the  project  documents.  Updates  to  these  documents  provide  greater  precision 
with  respect  to  schedule,  costs,  and  resource  requirements  to  meet  the  defined  project  scope. 

The  project  team  seeks  input  and  encourages  involvement  from  all  stakeholders  when  planning  the  project 
and  developing  the  project  management  plan  and  project  documents.  While  the  act  of  collecting  feedback  and 
refining  the  documents  cannot  continue  indefinitely,  procedures  set  by  the  organization  dictate  when  the  initial 
planning  ends.  These  procedures  will  be  affected  by  the  nature  of  the  project,  the  established  project  boundaries, 
appropriate  monitoring  and  controlling  activities,  as  well  as  the  environment  in  which  the  project  will  be  performed. 

Other  interactions  among  the  processes  within  the  Planning  Process  Group  are  dependent  upon  the  nature  of 
the  project.  For  example,  for  some  projects  there  will  be  little  or  no  identifiable  risks  until  after  a significant  amount 
of  planning  has  been  done.  At  that  time,  the  team  might  recognize  that  the  cost  and  schedule  targets  are  overly 
aggressive,  thus  involving  considerably  more  risk  than  previously  understood.  The  results  of  the  iterations  are 
documented  as  updates  to  the  project  management  plan  or  to  various  project  documents. 


3.5  Executing  Process  Group 

The  Executing  Process  Group  consists  of  those  processes  performed  to  complete  the  work  defined  in  the 
project  management  plan  to  satisfy  the  project  specifications.  This  Process  Group  involves  coordinating  people  and 
resources,  managing  stakeholder  expectations,  as  well  as  integrating  and  performing  the  activities  of  the  project  in 
accordance  with  the  project  management  plan. 

During  project  execution,  results  may  require  planning  updates  and  rebaselining.  This  may  include  changes 
to  expected  activity  durations,  changes  in  resource  productivity  and  availability,  and  unanticipated  risks.  Such 
variances  may  affect  the  project  management  plan  or  project  documents  and  may  require  detailed  analysis  and 
development  of  appropriate  project  management  responses.  The  results  of  the  analysis  can  trigger  change  requests 
that,  if  approved,  may  modify  the  project  management  plan  or  other  project  documents  and  possibly  require 
establishing  new  baselines.  A large  portion  of  the  project’s  budget  will  be  expended  in  performing  the  Executing 
Process  Group  processes. 
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3.6  Monitoring  and  Controlling  Process  Group 

The  Monitoring  and  Controlling  Process  Group  consists  of  those  processes  required  to  track,  review,  and 
orchestrate  the  progress  and  performance  of  the  project;  identify  any  areas  in  which  changes  to  the  plan  are 
required;  and  initiate  the  corresponding  changes.  The  key  benefit  of  this  Process  Group  is  that  project  performance 
is  measured  and  analyzed  at  regular  intervals,  appropriate  events,  or  exception  conditions  to  identify  variances 
from  the  project  management  plan.  The  Monitoring  and  Controlling  Process  Group  also  involves: 

• Controlling  changes  and  recommending  corrective  or  preventive  action  in  anticipation  of  possible 
problems, 

• Monitoring  the  ongoing  project  activities  against  the  project  management  plan  and  the  project 
performance  measurement  baseline,  and 

• Influencing  the  factors  that  could  circumvent  integrated  change  control  or  configuration  management 
so  only  approved  changes  are  implemented. 

This  continuous  monitoring  provides  the  project  team  insight  into  the  health  of  the  project  and  identifies  any 
areas  requiring  additional  attention.  The  Monitoring  and  Controlling  Process  Group  not  only  monitors  and  controls 
the  work  being  done  within  a Process  Group,  but  also  monitors  and  controls  the  entire  project  effort.  In  multiphase 
projects,  the  Monitoring  and  Controlling  Process  Group  coordinates  project  phases  in  order  to  implement  corrective 
or  preventive  actions  to  bring  the  project  into  compliance  with  the  project  management  plan.  This  review  can  result 
in  recommended  and  approved  updates  to  the  project  management  plan.  For  example,  a missed  activity  finish  date 
may  require  adjustments  and  trade-offs  between  budget  and  schedule  objectives.  In  order  to  reduce  or  control 
overhead,  management-by-exception  procedures  and  other  techniques  can  be  appropriately  considered. 


3.7  Closing  Process  Group 

The  Closing  Process  Group  consists  of  those  processes  performed  to  conclude  all  activities  across  all  Project 
Management  Process  Groups  to  formally  complete  the  project,  phase,  or  contractual  obligations.  This  Process 
Group,  when  completed,  verifies  that  the  defined  processes  are  completed  within  all  of  the  Process  Groups  to  close 
the  project  or  a project  phase,  as  appropriate,  and  formally  establishes  that  the  project  or  project  phase  is  complete. 
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This  Process  Group  also  formally  establishes  the  premature  closure  of  the  project.  Prematurely  closed  projects 
may  include,  for  example:  aborted  projects,  cancelled  projects,  and  projects  having  a critical  situation.  In  specific 
cases,  when  some  contracts  cannot  be  formally  closed  (e.g.  claims,  termination  clauses,  etc.)  or  some  activities 
are  to  be  transferred  to  other  organizational  units,  specific  hand-over  procedures  may  be  arranged  and  finalized. 

At  project  or  phase  closure,  the  following  may  occur: 

• Obtain  acceptance  by  the  customer  or  sponsor  to  formally  close  the  project  or  phase, 

• Conduct  post-project  or  phase-end  review, 

• Record  impacts  of  tailoring  to  any  process, 

• Document  lessons  learned, 

• Apply  appropriate  updates  to  organizational  process  assets, 

• Archive  all  relevant  project  documents  in  the  project  management  information  system  (PMIS)  to  be  used 
as  historical  data, 

• Close  out  all  procurement  activities  ensuring  termination  of  all  relevant  agreements,  and 

• Perform  team  members’  assessments  and  release  project  resources. 

3.8  Project  Information 

Throughout  the  life  cycle  of  the  project,  a significant  amount  of  data  and  information  is  collected,  analyzed, 
transformed,  and  distributed  in  various  formats  to  project  team  members  and  other  stakeholders.  Project  data  are 
collected  as  a result  of  various  Executing  processes  and  are  shared  within  the  project  team.  The  collected  data 
are  analyzed  in  context,  and  aggregated  and  transformed  to  become  project  information  during  various  Controlling 
processes.  The  information  may  then  be  communicated  verbally  or  stored  and  distributed  as  reports  in  various 
formats. 

The  project  data  are  continuously  collected  and  analyzed  during  the  dynamic  context  of  the  project  execution. 
As  a result,  the  terms  data  and  information  are  often  used  interchangeably  in  practice.  The  indiscriminate  use 
of  these  terms  can  lead  to  confusion  and  misunderstandings  by  the  various  project  stakeholders.  The  following 
guidelines  help  minimize  miscommunication  and  help  the  project  team  use  appropriate  terminology: 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKB  Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


3 - PROJECT  MANAGEMENT  PROCESSES 


• Work  performance  data.  The  raw  observations  and  measurements  identified  during  activities  performed 
to  carry  out  the  project  work.  Examples  include  reported  percent  of  work  physically  completed,  quality 
and  technical  performance  measures,  start  and  finish  dates  of  schedule  activities,  number  of  change 
requests,  number  of  defects,  actual  costs,  actual  durations,  etc. 

• Work  performance  information.  The  performance  data  collected  from  various  controlling  processes, 
analyzed  in  context  and  integrated  based  on  relationships  across  areas.  Examples  of  performance 
information  are  status  of  deliverables,  implementation  status  for  change  requests,  and  forecasted 
estimates  to  complete. 

• Work  performance  reports.  The  physical  or  electronic  representation  of  work  performance  information 
compiled  in  project  documents,  intended  to  generate  decisions  or  raise  issues,  actions,  or  awareness. 
Examples  include  status  reports,  memos,  justifications,  information  notes,  electronic  dashboards, 
recommendations,  and  updates. 

Figure  3-5  illustrates  the  flow  of  project  information  across  the  various  processes  used  to  manage  the  project. 


Figure  3-5.  Project  Data,  Information  and  Report  Flow 
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3.9  Role  of  the  Knowledge  Areas 

The  47  project  management  processes  identified  in  the  PMBOK®  Guide  are  further  grouped  into  ten  separate 
Knowledge  Areas.  A Knowledge  Area  represents  a complete  set  of  concepts,  terms,  and  activities  that  make  up 
a professional  field,  project  management  field,  or  area  of  specialization.  These  ten  Knowledge  Areas  are  used  on 
most  projects  most  of  the  time.  Project  teams  should  utilize  these  ten  Knowledge  Areas  and  other  Knowledge  Areas, 
as  appropriate,  for  their  specific  project.  The  Knowledge  Areas  are:  Project  Integration  Management,  Project  Scope 
Management,  Project  Time  Management,  Project  Quality  Management,  Project  Human  Resource  Management, 
Project  Communications  Management,  Project  Risk  Management,  Project  Procurement  Management  and  Project 
Stakeholder  Management.  Each  Knowledge  Area  within  the  PMBOK ® Guide  is  contained  in  a separate  section. 

The  PMBOK®  Guide  defines  the  important  aspects  of  each  Knowledge  Area  and  how  it  integrates  with  the 
five  Process  Groups.  As  supporting  elements,  the  Knowledge  Areas  provide  a detailed  description  of  the  process 
inputs  and  outputs  along  with  a descriptive  explanation  of  tools  and  techniques  most  frequently  used  within  the 
project  management  processes  to  produce  each  outcome.  A data  flow  diagram  is  provided  in  each  Knowledge 
Area  (Sections  4 through  8).  The  data  flow  diagram  is  a summary  level  depiction  of  the  process  inputs  and  process 
outputs  that  flow  down  through  all  the  processes  within  a specific  Knowledge  Area  (see  Figure  3-6  for  data  flow 
diagram  legend).  Although  the  processes  are  presented  here  as  discrete  elements  with  well-defined  interfaces,  in 
practice  they  are  iterative  and  can  overlap  and  interact  in  ways  not  detailed  here. 

Table  3-1  reflects  the  mapping  of  the  47  project  management  processes  within  the  5 Project  Management 
Process  Groups  and  the  1 0 Knowledge  Areas. 


Process  outside  of 
Knowledge  Area 

pi 

External  to  a Process 


Processes  within  a 
Knowledge  Area 

► Inter-knowledge  area  relationships 

► Extra-knowledge  area  relationships 

Process  flow 


The  data  flow  diagrams  show  basic  steps  and  interactions.  Many  additional  interactions  are  possible. 


Figure  3-6.  Data  Flow  Diagram  Legend 
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Table  3-1.  Project  Management  Process  Group  and  Knowledge  Area  Mapping 
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PROJECT  INTEGRATION  MANAGEMENT 


Project  Integration  Management  includes  the  processes  and  activities  to  identify,  define,  combine,  unify,  and 
coordinate  the  various  processes  and  project  management  activities  within  the  Project  Management  Process 
Groups.  In  the  project  management  context,  integration  includes  characteristics  of  unification,  consolidation, 
communication,  and  integrative  actions  that  are  crucial  to  controlled  project  execution  through  completion, 
successfully  managing  stakeholder  expectations,  and  meeting  requirements.  Project  Integration  Management 
includes  making  choices  about  resource  allocation,  making  trade-offs  among  competing  objectives  and 
alternatives,  and  managing  the  interdependencies  among  the  project  management  Knowledge  Areas.  The 
project  management  processes  are  usually  presented  as  discrete  processes  with  defined  interfaces  while,  in 
practice,  they  overlap  and  interact  in  ways  that  cannot  be  completely  detailed  in  the  PMBOK ® Guide. 

Figure  4-1  provides  an  overview  of  the  Project  Integration  Management  processes,  which  are  as  follows: 

4.1  Develop  Project  Charter — The  process  of  developing  a document  that  formally  authorizes  the 
existence  of  a project  and  provides  the  project  manager  with  the  authority  to  apply  organizational 
resources  to  project  activities. 

4.2  Develop  Project  Management  Plan — The  process  of  defining,  preparing,  and  coordinating  all 
subsidiary  plans  and  integrating  them  into  a comprehensive  project  management  plan.  The  project’s 
integrated  baselines  and  subsidiary  plans  may  be  included  within  the  project  management  plan. 

4.3  Direct  and  Manage  Project  Work — The  process  of  leading  and  performing  the  work  defined  in  the 
project  management  plan  and  implementing  approved  changes  to  achieve  the  project’s  objectives. 

4.4  Monitor  and  Control  Project  Work — The  process  of  tracking,  reviewing,  and  reporting  project 
progress  against  the  performance  objectives  defined  in  the  project  management  plan. 

4.5  Perform  Integrated  Change  Control — The  process  of  reviewing  all  change  requests;  approving 
changes  and  managing  changes  to  deliverables,  organizational  process  assets,  project  documents, 
and  the  project  management  plan;  and  communicating  their  disposition. 

4.6  Close  Project  or  Phase — The  process  of  finalizing  all  activities  across  all  of  the  Project  Management 
Process  Groups  to  formally  complete  the  phase  or  project. 
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These  processes  interact  with  each  other  and  with  processes  in  other  Knowledge  Areas  as  described  in  detail 
in  Section  3 and  Annex  A1. 

The  need  for  Project  Integration  Management  is  necessary  in  situations  where  individual  processes  interact. 
For  example,  a cost  estimate  needed  for  a contingency  plan  involves  integrating  the  processes  in  the  Project  Cost, 
Time,  and  Risk  Management  Knowledge  Areas.  When  additional  risks  associated  with  various  staffing  alternatives 
are  identified,  then  one  or  more  of  those  processes  may  be  revisited.  The  project  deliverables  may  also  need 
integrating  with  ongoing  operations  of  the  performing  organization,  the  requesting  organization,  and  with  the 
long-term  strategic  planning  that  takes  future  problems  and  opportunities  into  consideration.  Project  Integration 
Management  also  includes  the  activities  needed  to  manage  project  documents  to  ensure  consistency  with  the 
project  management  plan  and  product,  service,  or  capability  deliverables. 

Most  experienced  project  management  practitioners  know  there  is  no  single  way  to  manage  a project.  They 
apply  project  management  knowledge,  skills,  and  required  processes  in  a preferred  order  and  with  varying  rigor  to 
achieve  the  desired  project  performance.  However,  the  determination  that  a particular  process  is  not  required  does 
not  mean  that  it  should  not  be  addressed.  The  project  manager  and  project  team  need  to  address  every  process  and 
the  project  environment  to  determine  the  level  of  implementation  for  each  process  within  the  project.  If  a project 
has  more  than  one  phase,  the  level  of  rigor  applied  within  each  of  the  project  phases  should  be  appropriate  for  each 
phase.  This  determination  is  also  addressed  by  the  project  manager  and  project  team. 

The  integrative  nature  of  projects  and  project  management  can  be  understood  by  thinking  of  other  types  of 
activities  performed  while  completing  a project.  Examples  of  some  activities  performed  by  the  project  management 
team  are: 

• Develop,  review,  analyze,  and  understand  the  scope.  This  includes  the  project  and  product  requirements, 
criteria,  assumptions,  constraints,  and  other  influences  related  to  a project,  and  how  each  will  be  managed 
or  addressed  within  the  project; 

• Transform  the  collected  project  information  into  a project  management  plan  using  a structured  approach 
as  described  in  the  PMBOK®  Guide-, 

• Perform  activities  to  produce  project  deliverables;  and 

• Measure  and  monitor  the  project’s  progress  and  take  appropriate  action  to  meet  project  objectives. 
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The  links  among  the  processes  in  the  Project  Management  Process  Groups  are  often  iterative  in  nature.  For 
example,  the  Planning  Process  Group  provides  the  Executing  Process  Group  with  a documented  project  management 
plan  early  in  the  project  and  then  updates  the  project  management  plan  if  changes  occur  as  the  project  progresses. 
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Figure  4-1 . Project  Integration  Management  Overview 
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4.1  Develop  Project  Charter 

Develop  Project  Charter  is  the  process  of  developing  a document  that  formally  authorizes  the  existence  of  a 
project  and  provides  the  project  manager  with  the  authority  to  apply  organizational  resources  to  project  activities. 
The  key  benefit  of  this  process  is  a well-defined  project  start  and  project  boundaries,  creation  of  a formal  record  of 
the  project,  and  a direct  way  for  senior  management  to  formally  accept  and  commit  to  the  project.  The  inputs,  tools 
and  techniques,  and  outputs  for  this  process  are  shown  in  Figure  4-2.  Figure  4-3  depicts  the  data  flow  diagram  of 
the  process. 
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Figure  4-2.  Develop  Project  Charter:  Inputs,  Tools  and  Techniques,  and  Outputs 
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Figure  4-3.  Develop  Project  Charter  Data  Flow  Diagram 

The  project  charter  establishes  a partnership  between  the  performing  and  requesting  organizations.  In  the 
case  of  external  projects,  a formal  contract  is  typically  the  preferred  way  to  establish  an  agreement.  In  this 
case,  the  project  team  becomes  the  seller  responding  to  conditions  of  an  offer  to  buy  from  an  outside  entity. 
A project  charter  is  still  used  to  establish  internal  agreements  within  an  organization  to  assure  proper  delivery 
under  the  contract.  The  approved  project  charter  formally  initiates  the  project.  A project  manager  is  identified 
and  assigned  as  early  in  the  project  as  is  feasible,  preferably  while  the  project  charter  is  being  developed  and 
always  prior  to  the  start  of  planning.  The  project  charter  should  be  authored  by  the  sponsoring  entity.  The  project 
charter  provides  the  project  manager  with  the  authority  to  plan  and  execute  the  project.  It  is  recommended 
that  the  project  manager  participate  in  the  development  of  the  project  charter  to  obtain  a foundational 
understanding  of  the  project  requirements.  This  understanding  will  better  allow  for  efficient  resources  allocation 
to  project  activities. 
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Projects  are  initiated  by  an  entity  external  to  the  project  such  as  a sponsor,  program  or  project  management 
office  (PMO)  staff  person,  or  a portfolio  governing  body  chairperson  or  authorized  representative.  The  project 
initiator  or  sponsor  should  be  at  the  level  that  is  appropriate  to  procure  funding  and  commit  resources  to  the 
project.  Projects  are  initiated  due  to  internal  business  needs  or  external  influences.  These  needs  or  influences 
often  trigger  the  creation  of  a needs  analysis,  feasibility  study,  business  case,  or  description  of  the  situation  that 
the  project  will  address.  Chartering  a project  validates  alignment  of  the  project  to  the  strategy  and  ongoing  work  of 
the  organization.  A project  charter  is  not  considered  to  be  a contract,  because  there  is  no  consideration  or  money 
promised  or  exchanged  in  its  creation. 

4.1.1  Develop  Project  Charter:  Inputs 

4.1 .1 .1  Project  Statement  of  Work 

The  project  statement  of  work  (SOW)  is  a narrative  description  of  products,  services,  or  results  to  be  delivered 
by  a project.  For  internal  projects,  the  project  initiator  or  sponsor  provides  the  statement  of  work  based  on  business 
needs,  product,  or  service  requirements.  For  external  projects,  the  statement  of  work  can  be  received  from  the 
customer  as  part  of  a bid  document,  (e.g.,  a request  for  proposal,  request  for  information,  or  request  for  bid)  or  as 
part  of  a contract.  The  SOW  references  the  following: 

• Business  need.  An  organization’s  business  need  may  be  based  on  a market  demand,  technological 
advance,  legal  requirement,  government  regulation,  or  environmental  consideration.  Typically,  the 
business  need  and  the  cost-benefit  analysis  are  contained  in  the  business  case  to  justify  the  project. 

• Product  scope  description.  The  product  scope  description  documents  the  characteristics  of  the  product, 
service,  or  results  that  the  project  will  be  undertaken  to  create.  The  description  should  also  document 
the  relationship  between  the  products,  services,  or  results  being  created  and  the  business  need  that  the 
project  will  address. 

• Strategic  plan.  The  strategic  plan  documents  the  organization’s  strategic  vision,  goals,  and  objectives 
and  may  contain  a high-level  mission  statement.  All  projects  should  be  aligned  with  their  organization’s 
strategic  plan.  Strategic  plan  alignment  ensures  that  each  project  contributes  to  the  overall  objections  of 
the  organization. 
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4.1 .1 .2  Business  Case 

The  business  case  or  similar  document  describes  the  necessary  information  from  a business  standpoint  to 
determine  whether  or  not  the  project  is  worth  the  required  investment.  It  is  commonly  used  for  decision  making 
by  managers  or  executives  above  the  project  level.  Typically,  the  business  need  and  the  cost-benefit  analysis  are 
contained  in  the  business  case  to  justify  and  establish  boundaries  for  the  project,  and  such  analysis  is  usually 
completed  by  a business  analyst  using  various  stakeholder  inputs.  The  sponsor  should  agree  to  the  scope  and 
limitations  of  the  business  case.  The  business  case  is  created  as  a result  of  one  or  more  of  the  following: 

• Market  demand  (e.g.,  a car  company  authorizing  a project  to  build  more  fuel-efficient  cars  in  response 
to  gasoline  shortages), 

• Organizational  need  (e.g.,  due  to  high  overhead  costs  a company  may  combine  staff  functions  and 
streamline  processes  to  reduce  costs.), 

• Customer  request  (e.g.,  an  electric  utility  authorizing  a project  to  build  a new  substation  to  serve  a new 
industrial  park), 

• Technological  advance  (e.g.,  an  airline  authorizing  a new  project  to  develop  electronic  tickets  instead  of 
paper  tickets  based  on  technological  advances), 

• Legal  requirement  (e.g.,  a paint  manufacturer  authorizing  a project  to  establish  guidelines  for  handling 
toxic  materials), 

• Ecological  impacts  (e.g.,  a company  authorizing  a project  to  lessen  its  environmental  impact),  or 

• Social  need  (e.g.,  a nongovernmental  organization  in  a developing  country  authorizing  a project  to  provide 
potable  water  systems,  latrines,  and  sanitation  education  to  communities  suffering  from  high  rates  of 
cholera). 

Each  of  the  examples  in  this  list  may  contain  elements  of  risk  that  should  be  addressed.  In  the  case  of  multiphase 
projects,  the  business  case  may  be  periodically  reviewed  to  ensure  that  the  project  is  on  track  to  deliver  the 
business  benefits.  In  the  early  stages  of  the  project  life  cycle,  periodic  review  of  the  business  case  by  the  sponsoring 
organization  also  helps  to  confirm  that  the  project  is  still  aligned  with  the  business  case.  The  project  manager  is 
responsible  for  ensuring  that  the  project  effectively  and  efficiently  meets  the  goals  of  the  organization  and  those 
requirements  of  a broad  set  of  stakeholders,  as  defined  in  the  business  case. 
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4.1 .1 .3  Agreements 

Agreements  are  used  to  define  initial  intentions  for  a project.  Agreements  may  take  the  form  of  contracts, 
memorandums  of  understanding  (MOUs),  service  level  agreements  (SLA),  letter  of  agreements,  letters  of  intent, 
verbal  agreements,  email,  or  other  written  agreements.  Typically,  a contract  is  used  when  a project  is  being 
performed  for  an  external  customer. 

4.1 .1 .4  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  The  enterprise  environmental  factors  that  can  influence  the  Develop  Project  Charter 
process  include,  but  are  not  limited  to: 

• Governmental  standards,  industry  standards,  or  regulations  (e.g.  codes  of  conduct,  quality  standards, 
or  worker  protection  standards), 

• Organizational  culture  and  structure,  and 

• Marketplace  conditions. 

4.1 .1 .5  Organizational  Process  Assets 

Described  in  Section  2.1.4.  The  organizational  process  assets  that  can  influence  the  Develop  Project  Charter 
process  include,  but  are  not  limited  to: 

• Organizational  standard  processes,  policies,  and  process  definitions, 

• Templates  (e.g.,  project  charter  template),  and 

• Historical  information  and  lessons  learned  knowledge  base  (e.g.,  projects,  records,  and  documents;  all 
project  closure  information  and  documentation;  information  about  both  the  results  of  previous  project 
selection  decisions  and  previous  project  performance  information;  and  information  from  the  risk 
management  activity). 
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4.1.2  Develop  Project  Charter:  Tools  and  Techniques 

4.1 .2.1  Expert  Judgment 

Expert  judgment  is  often  used  to  assess  the  inputs  used  to  develop  the  project  charter.  Expert  judgment  is 
applied  to  all  technical  and  management  details  during  this  process.  Such  expertise  is  provided  by  any  group  or 
individual  with  specialized  knowledge  or  training  and  is  available  from  many  sources,  including: 

• Other  units  within  the  organization, 

• Consultants, 

• Stakeholders,  including  customers  or  sponsors, 

• Professional  and  technical  associations, 

• Industry  groups, 

• Subject  matter  experts  (SME),  and 

• Project  management  office  (PMO). 

4.1 .2.2  Facilitation  Techniques 

Facilitation  techniques  have  broad  application  within  project  management  processes  and  guide  the 
development  of  the  project  charter.  Brainstorming,  conflict  resolution,  problem  solving,  and  meeting 
management  are  examples  of  key  techniques  used  by  facilitators  to  help  teams  and  individuals  accomplish 
project  activities. 

4.1 .3  Develop  Project  Charter:  Outputs 

4.1 .3.1  Project  Charter 

The  project  charter  is  the  document  issued  by  the  project  initiator  or  sponsor  that  formally  authorizes  the 
existence  of  a project  and  provides  the  project  manager  with  the  authority  to  apply  organizational  resources  to 
project  activities.  It  documents  the  business  needs,  assumptions,  constraints,  the  understanding  of  the  customer’s 
needs  and  high-level  requirements,  and  the  new  product,  service,  or  result  that  it  is  intended  to  satisfy,  such  as: 
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• Project  purpose  or  justification, 

• Measurable  project  objectives  and  related  success  criteria, 

• High-level  requirements, 

• Assumptions  and  constraints, 

• High-level  project  description  and  boundaries, 

• High-level  risks, 

• Summary  milestone  schedule, 

• Summary  budget, 

• Stakeholder  list, 

• Project  approval  requirements  (i.e.,  what  constitutes  project  success,  who  decides  the  project  is 
successful,  and  who  signs  off  on  the  project), 

• Assigned  project  manager,  responsibility,  and  authority  level,  and 

• Name  and  authority  of  the  sponsor  or  other  person(s)  authorizing  the  project  charter. 

4.2  Develop  Project  Management  Plan 

Develop  Project  Management  Plan  is  the  process  of  defining,  preparing,  and  coordinating  all  subsidiary  plans 
and  integrating  them  into  a comprehensive  project  management  plan.  The  key  benefit  of  this  process  is  a central 
document  that  defines  the  basis  of  all  project  work.  The  inputs,  tools  and  techniques,  and  outputs  for  this  process 
are  depicted  in  Figure  4-4.  Figure  4-5  depicts  the  data  flow  diagram  of  the  process. 
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Figure  4-3.  Develop  Project  Charter  Data  Flow  Diagram 
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The  project  management  plan  defines  how  the  project  is  executed,  monitored  and  controlled,  and  closed.  The 
project  management  plan’s  content  varies  depending  upon  the  application  area  and  complexity  of  the  project.  It 
is  developed  through  a series  of  integrated  processes  extending  through  project  closure.  This  process  results  in 
a project  management  plan  that  is  progressively  elaborated  by  updates,  and  controlled  and  approved  through  the 
Perform  Integrated  Change  Control  (Section  4.5)  process.  Projects  that  exist  in  the  context  of  a program  should 
develop  a project  management  plan  that  is  consistent  with  the  program  management  plan.  For  example,  if  the 
program  management  plan  indicates  all  changes  exceeding  a specified  cost  need  to  be  reviewed  by  the  change 
control  board  (CCB),  then  this  process  and  cost  threshold  needs  to  be  defined  in  the  project  management  plan. 

4.2.1  Develop  Project  Management  Plan:  Inputs 

4.2.1 .1  Project  Charter 

Described  in  Section  4. 1.3.1.  The  size  of  the  project  charter  varies  depending  on  the  complexity  of  the 
project  and  the  information  known  at  the  time  of  its  creation.  At  a minimum,  the  project  charter  should  define 
the  high-level  boundaries  of  the  project.  The  project  manager  uses  the  project  charter  as  the  starting  point 
for  initial  planning  throughout  the  Initiating  Process  Group. 

4.2.1 .2  Outputs  from  Other  Processes 

Outputs  from  many  of  the  other  processes  described  in  Sections  5 through  13  are  integrated  to  create  the 
project  management  plan.  Any  baselines  and  subsidiary  plans  that  are  an  output  from  other  planning  processes 
are  inputs  to  this  process.  In  addition,  changes  to  these  documents  may  necessitate  updates  to  the  project 
management  plan. 

4.2.1 .3  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  The  enterprise  environmental  factors  that  can  influence  the  Develop  Project 
Management  Plan  process  include,  but  are  not  limited  to: 

• Governmental  or  industry  standards; 

• Project  management  body  of  knowledge  for  vertical  market  (e.g.,  construction)  and/or  focus  area 
(e.g.  environmental,  safety,  risk,  or  agile  software  development); 

• Project  management  information  system  (e.g.,  an  automated  tool,  such  as  a scheduling  software  tool,  a 
configuration  management  system,  an  information  collection  and  distribution  system,  or  web  interfaces 
to  other  online  automated  systems); 
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• Organizational  structure,  culture,  management  practices,  and  sustainability; 

• Infrastructure  (e.g.,  existing  facilities  and  capital  equipment);  and 

• Personnel  administration  (e.g.,  hiring  and  termination  guidelines,  employee  performance  reviews,  and 
employee  development  and  training  records). 

4.2.1 .4  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  can  influence  the  Develop  Project  Management 
Plan  process  include,  but  are  not  limited  to: 

• Standardized  guidelines,  work  instructions,  proposal  evaluation  criteria,  and  performance  measurement 
criteria; 

• Project  management  plan  template,  including: 

o Guidelines  and  criteria  for  tailoring  the  organization’s  set  of  standard  processes  to  satisfy  the 
specific  needs  of  the  project,  and 

o Project  closure  guidelines  or  requirements  such  as  the  product  validation  and  acceptance 
criteria; 

• Change  control  procedures,  including  the  steps  by  which  official  organization  standards,  policies,  plans, 
and  procedures,  or  any  project  documents  will  be  modified  and  how  any  changes  will  be  approved  and 
validated; 

• Project  files  from  previous  projects  (e.g.,  scope,  cost,  schedule  and  performance  measurement  baselines, 
project  calendars,  project  schedule  network  diagrams,  and  risk  registers,); 

• Historical  information  and  lessons  learned  knowledge  base;  and 

• Configuration  management  knowledge  base  containing  the  versions  and  baselines  of  all  official 
organization  standards,  policies,  procedures,  and  any  project  documents. 
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4.2.2  Develop  Project  Management  Plan:  Tools  and  Techniques 

4.2.2.1  Expert  Judgment 

When  developing  the  project  management  plan,  expert  judgment  is  utilized  to: 

• Tailor  the  process  to  meet  the  project  needs, 

• Develop  technical  and  management  details  to  be  included  in  the  project  management  plan, 

• Determine  resources  and  skill  levels  needed  to  perform  project  work, 

• Define  the  level  of  configuration  management  to  apply  on  the  project, 

• Determine  which  project  documents  will  be  subject  to  the  formal  change  control  process,  and 

• Prioritize  the  work  on  the  project  to  ensure  the  project  resources  are  allocated  to  the  appropriate  work 
at  the  appropriate  time. 

4.2.2.2  Facilitation  Techniques 

Described  in  Section  4. 1.2. 2.  Facilitation  techniques  have  broad  application  within  project  management 
processes  and  are  used  to  guide  the  development  of  the  project  management  plan.  Brainstorming,  conflict 
resolution,  problem  solving,  and  meeting  management  are  key  techniques  used  by  facilitators  to  help  teams  and 
individuals  achieve  agreement  to  accomplish  project  activities. 

4.2.3  Develop  Project  Management  Plan:  Outputs 
4.2.3.1  Project  Management  Plan 

The  project  management  plan  is  the  document  that  describes  how  the  project  will  be  executed,  monitored,  and 
controlled.  It  integrates  and  consolidates  all  of  the  subsidiary  plans  and  baselines  from  the  planning  processes. 

Project  baselines  include,  but  are  not  limited  to: 

• Scope  baseline  (Section  5. 4.3.1), 

• Schedule  baseline  (Section  6.6. 3.1),  and 

• Cost  baseline  (Section  7. 3.3.1). 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKB  Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


4 - PROJECT  INTEGRATION  MANAGEMENT 


Subsidiary  plans  include,  but  are  not  limited  to: 

• Scope  management  plan  (Section  5.1 .3.1 ), 

• Requirements  management  plan  (Section  5.1 .3.2), 

• Schedule  management  plan  (Section  6.1 .3.1), 

• Cost  management  plan  (Section  7.1 .3.1), 

• Quality  management  plan  (Section  8.1 .3.1), 

• Process  improvement  plan  (Section  8.1 .3.2), 

• Human  resource  management  plan  (Section  9.1 .3.1), 

• Communications  management  plan  (Section  10.1.3.1), 

• Risk  management  plan  (Section  1 1 .1 .3.1 ), 

• Procurement  management  plan  (Section  1 2.1 .3.1 ),  and 

• Stakeholder  management  plan  (Section  1 3.2. 3.1 ). 

Among  other  things,  the  project  management  plan  may  also  include  the  following: 

• Life  cycle  selected  for  the  project  and  the  processes  that  will  be  applied  to  each  phase; 

• Details  of  the  tailoring  decisions  specified  by  the  project  management  team  as  follows: 

o Project  management  processes  selected  by  the  project  management  team, 
o Level  of  implementation  for  each  selected  process, 

o Descriptions  of  the  tools  and  techniques  to  be  used  for  accomplishing  those  processes,  and 

o Description  of  how  the  selected  processes  will  be  used  to  manage  the  specific  project,  including 
the  dependencies  and  interactions  among  those  processes  and  the  essential  inputs  and  outputs. 

• Description  of  how  work  will  be  executed  to  accomplish  the  project  objectives; 

• Change  management  plan  that  documents  how  changes  will  be  monitored  and  controlled; 

• Configuration  management  plan  that  documents  how  configuration  management  will  be  performed; 

• Description  of  how  the  integrity  of  the  project  baselines  will  be  maintained; 

• Requirements  and  techniques  for  communication  among  stakeholders;  and 

• Key  management  reviews  for  content,  the  extent  of,  and  timing  to  address,  open  issues  and  pending 
decisions. 
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The  project  management  plan  may  be  either  summary  level  or  detailed,  and  may  be  composed  of  one  or  more 
subsidiary  plans.  Each  of  the  subsidiary  plans  is  detailed  to  the  extent  required  by  the  specific  project.  Once  the 
project  management  plan  is  baselined,  it  may  only  be  changed  when  a change  request  is  generated  and  approved 
through  the  Perform  Integrated  Change  Control  process. 

While  the  project  management  plan  is  one  of  the  primary  documents  used  to  manage  the  project,  other  project 
documents  are  also  used.  These  other  documents  are  not  part  of  the  project  management  plan.  Table  4-1  is  a 
representative  list  of  the  project  management  plan  components  and  project  documents. 


Table  4-1  Differentiation  Between  the  Project  Management  Plan  and  Project  Documents 


Project  Management  Plan 

Project  Documents 

Change  management  plan 

Activity  attributes 

Project  staff  assignments 

Communications  management  plan 

Activity  cost  estimates 

Project  statement  of  work 

Configuration  management  plan 

Activity  duration  estimates 

Quality  checklists 

Cost  baseline 

Activity  list 

Quality  control  measurements 

Cost  management  plan 

Activity  resource  requirements 

Quality  metrics 

Human  resource  management  plan 

Agreements 

Requirements  documentation 

Process  improvement  plan 

Basis  of  estimates 

Requirements  traceability  matrix 

Procurement  management  plan 

Change  log 

Resource  breakdown  structure 

Scope  baseline 

• Project  scope  statement 

• WBS 

• WBS  dictionary 

Change  requests 

Resource  calendars 

Quality  management  plan 

Forecasts 

• Cost  forecast 

• Schedule  forecast 

Risk  register 

Requirements  management  plan 

Issue  log 

Schedule  data 

Risk  management  plan 

Milestone  list 

Seller  proposals 

Schedule  baseline 

Procurement  documents 

Source  selection  criteria 

Schedule  management  plan 

Procurement  statement  of  work 

Stakeholder  register 

Scope  management  plan 

Project  calendars 

Team  performance  assessments 

Stakeholder  management  plan 
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4.3  Direct  and  Manage  Project  Work 

Direct  and  Manage  Project  Work  is  the  process  of  leading  and  performing  the  work  defined  in  the  project 
management  plan  and  implementing  approved  changes  to  achieve  the  project’s  objectives.  The  key  benefit  of  this 
process  is  that  it  provides  overall  management  of  the  project  work.  The  inputs,  tools  and  techniques,  and  outputs 
of  this  process  are  depicted  in  Figure  4-6.  Figure  4-7  depicts  the  data  flow  diagram  of  the  process. 
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Figure  4-6.  Direct  and  Manage  Project  Work:  Inputs,  Tools  and  Techniques,  and  Outputs 
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Direct  and  Manage  Project  Work  activities  include,  but  are  not  limited  to: 

• Perform  activities  to  accomplish  project  objectives; 

• Create  project  deliverables  to  meet  the  planned  project  work; 

• Provide,  train,  and  manage  the  team  members  assigned  to  the  project; 

• Obtain,  manage,  and  use  resources  including  materials,  tools,  equipment,  and  facilities; 
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• Implement  the  planned  methods  and  standards; 

• Establish  and  manage  project  communication  channels,  both  external  and  internal  to  the  project  team; 

• Generate  work  performance  data,  such  as  cost,  schedule,  technical  and  quality  progress,  and  status  to 
facilitate  forecasting; 

• Issue  change  requests  and  implement  approved  changes  into  the  project’s  scope,  plans,  and  environment; 

• Manage  risks  and  implement  risk  response  activities; 

• Manage  sellers  and  suppliers; 

• Manage  stakeholders  and  their  engagement;  and 

• Collect  and  document  lessons  learned  and  implement  approved  process  improvement  activities. 

The  project  manager,  along  with  the  project  management  team,  directs  the  performance  of  the  planned  project 
activities  and  manages  the  various  technical  and  organizational  interfaces  that  exist  within  the  project.  The  project 
manager  should  also  manage  any  unplanned  activities  and  determine  the  appropriate  course  of  action.  The  Direct 
and  Manage  Project  Work  process  is  directly  affected  by  the  project  application  area.  Deliverables  are  produced 
as  outputs  from  processes  performed  to  accomplish  the  project  work  as  planned  and  scheduled  in  the  project 
management  plan. 

During  project  execution,  the  work  performance  data  is  collected  and  appropriately  actioned  and  communicated. 
Work  performance  data  includes  information  about  the  completion  status  of  deliverables  and  other  relevant 
details  about  project  performance.  The  work  performance  data  will  also  be  used  as  an  input  to  the  Monitoring  and 
Controlling  Process  Group. 

Direct  and  Manage  Project  Work  also  requires  review  of  the  impact  of  all  project  changes  and  the  implementation 
of  approved  changes: 

• Corrective  action — An  intentional  activity  that  realigns  the  performance  of  the  project  work  with  the 
project  management  plan; 

• Preventive  action — An  intentional  activity  that  ensures  the  future  performance  of  the  project  work  is 
aligned  with  the  project  management  plan;  and/or 

• Defect  repair — An  intentional  activity  to  modify  a nonconforming  product  or  product  component. 
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4.3.1  Direct  and  Manage  Project  Work:  Inputs 

4.3.1 .1  Project  Management  Plan 

Described  in  Section  4. 2.3.1  .The  project  management  plan  contains  subsidiary  plans  concerning  all  aspects  of 
the  project.  Those  subsidiary  plans  related  to  project  work  include,  but  are  not  limited  to: 

• Scope  management  plan  (Section  5.1 .3.1), 

• Requirements  management  plan  (Section  5.1 .3.2), 

• Schedule  management  plan  (Section  6.1 .3.1), 

• Cost  management  plan  (Section  7.1 .3.1 ),  and 

• Stakeholder  management  plan  (Section  1 3.2. 3.1 ). 

4.3.1 .2  Approved  Change  Requests 

Approved  change  requests  are  an  output  of  the  Perform  Integrated  Change  Control  process,  and  include  those 
requests  reviewed  and  approved  for  implementation  by  the  change  control  board  (CCB).  The  approved  change 
request  may  be  a corrective  action,  a preventative  action,  or  a defect  repair.  Approved  change  requests  are 
scheduled  and  implemented  by  the  project  team,  and  can  impact  any  area  of  the  project  or  project  management 
plan.  The  approved  change  requests  can  also  modify  the  policies,  project  management  plan,  procedures,  costs, 
or  budgets  or  revise  the  schedules.  Approved  change  requests  may  require  implementation  of  preventive  or 
corrective  actions. 

4.3.1 .3  Enterprise  Environmental  Factors 

Described  in  Section  2.1.5.  The  Direct  and  Manage  Project  Work  process  is  influenced  by  enterprise 
environmental  factors  that  include,  but  are  not  limited  to: 

• Organizational,  company,  or  customer  culture  and  structure  of  the  performing  or  sponsor  organizations; 

• Infrastructure  (e.g.,  existing  facilities  and  capital  equipment); 

• Personnel  administration  (e.g.,  hiring  and  firing  guidelines,  employee  performance  reviews,  and  training 
records); 

• Stakeholder  risk  tolerances,  for  example  allowable  cost  overrun  percentage;  and 

• Project  management  information  system  (e.g.,  an  automated  tool  suite,  such  as  a scheduling  software 
tool,  a configuration  management  system,  an  information  collection  and  distribution  system,  or  web 
interfaces  to  other  online  automated  systems). 
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4.3.1 .4  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  can  influence  the  Direct  and  Manage  Project 
Work  process  include,  but  are  not  limited  to: 

• Standardized  guidelines  and  work  instructions; 

• Communication  requirements  defining  allowed  communication  media,  record  retention,  and  security 
requirements; 

• Issue  and  defect  management  procedures  defining  issue  and  defect  controls,  issue  and  defect 
identification  and  resolution,  and  action  item  tracking; 

• Process  measurement  database  used  to  collect  and  make  available  measurement  data  on  processes 
and  products; 

• Project  files  from  previous  projects  (e.g.,  scope,  cost,  schedule,  performance  measurement  baselines, 
project  calendars,  project  schedule,  network  diagrams,  risk  registers,  planned  response  actions,  defined 
risk  impact,  and  documented  lessons  learned);  and 

• Issue  and  defect  management  database(s)  containing  historical  issue  and  defect  status,  control 
information,  issue  and  defect  resolution,  and  action  item  results. 

4.3.2  Direct  and  Manage  Project  Work:  Tools  and  Techniques 

4.3.2.1  Expert  Judgment 

Expert  judgment  is  used  to  assess  the  inputs  needed  to  direct  and  manage  execution  of  the  project  management 
plan.  Such  judgment  and  expertise  are  applied  to  all  technical  and  management  details  during  this  process.  This 
expertise  is  provided  by  the  project  manager  and  the  project  management  team  using  specialized  knowledge  or 
training.  Additional  expertise  is  available  from  many  sources,  including: 

• Other  units  within  the  organization; 

• Consultants  and  other  subject  matter  experts  (internal  and  external); 

• Stakeholders,  including  customers,  suppliers,  or  sponsors;  and 

• Professional  and  technical  associations. 
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4.3.2.2  Project  Management  Information  System 

The  project  management  information  system,  which  is  part  of  the  environmental  factors,  provides  access  to 
tools,  such  as  a scheduling  tool,  a work  authorization  system,  a configuration  management  system,  an  information 
collection  and  distribution  system,  or  interfaces  to  other  online  automated  systems.  Automated  gathering  and 
reporting  on  key  performance  indicators  (KPI)  can  be  part  of  this  system. 

4.3.2.3  Meetings 

Meetings  are  used  to  discuss  and  address  pertinent  topics  of  the  project  when  directing  and  managing  project 
work.  Attendees  at  the  meetings  may  include  the  project  manager,  the  project  team  and  appropriate  stakeholders 
involved  or  affected  by  the  topics  addressed.  Each  attendee  should  have  a defined  role  to  ensure  appropriate 
participation.  Meetings  tend  to  be  one  of  three  types: 

• Information  exchange; 

• Brainstorming,  option  evaluation,  or  design;  or 

• Decision  making. 

Meeting  types  should  not  be  mixed  as  a best  practice.  Meetings  should  be  prepared  with  a well-defined  agenda, 
purpose,  objective,  and  time  frame  and  should  be  appropriately  documented  with  meeting  minutes  and  action 
items.  Meeting  minutes  should  be  stored  as  defined  in  the  project  management  plan.  Meetings  are  most  effective 
when  all  participants  can  be  face-to-face  in  the  same  location.  Virtual  meetings  can  be  held  using  audio  and / 
or  video  conferencing  tools,  but  generally  require  additional  preparation  and  organization  to  achieve  the  same 
effectiveness  of  a face-to-face  meeting. 

4.3.3  Direct  and  Manage  Project  Work:  Outputs 
4.3.3.1  Deliverables 

A deliverable  is  any  unique  and  verifiable  product,  result  or  capability  to  perform  a service  that  is  required  to  be 
produced  to  complete  a process,  phase,  or  project.  Deliverables  are  typically  tangible  components  completed  to 
meet  the  project  objectives  and  can  include  elements  of  the  project  management  plan. 
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4.3.3.2  Work  Performance  Data 

Work  performance  data  are  the  raw  observations  and  measurements  identified  during  activities  being  performed 
to  carry  out  the  project  work.  Data  are  often  viewed  as  the  lowest  level  of  detail  from  which  information  is  derived 
by  other  processes.  Data  is  gathered  through  work  execution  and  passed  to  the  controlling  processes  of  each 
process  area  for  further  analysis. 

Examples  of  work  performance  data  include  work  completed,  key  performance  indicators,  technical  performance 
measures,  start  and  finish  dates  of  schedule  activities,  number  of  change  requests,  number  of  defects,  actual  costs, 
and  actual  durations,  etc. 

4.3.3.3  Change  Requests 

A change  request  is  a formal  proposal  to  modify  any  document,  deliverable,  or  baseline.  An  approved  change 
request  will  replace  the  associated  document,  deliverable,  or  baseline  and  may  result  in  an  update  to  other  parts 
of  the  project  management  plan.  When  issues  are  found  while  project  work  is  being  performed,  change  requests 
are  submitted,  which  may  modify  project  policies  or  procedures,  project  scope,  project  cost  or  budget,  project 
schedule,  or  project  quality.  Other  change  requests  cover  the  needed  preventive  or  corrective  actions  to  forestall 
negative  impact  later  in  the  project.  Requests  for  a change  can  be  direct  or  indirect,  externally  or  internally  initiated, 
and  can  be  optional  or  legally/contractually  mandated,  and  may  include: 

• Corrective  action — An  intentional  activity  that  realigns  the  performance  of  the  project  work  with  the 
project  management  plan; 

• Preventive  action — An  intentional  activity  that  ensures  the  future  performance  of  the  project  work  is 
aligned  with  the  project  management  plan; 

• Defect  repair — An  intentional  activity  to  modify  a nonconforming  product  or  product  component;  and/or 

• Updates — Changes  to  formally  controlled  project  documents,  plans,  etc.,  to  reflect  modified  or  additional 
ideas  or  content. 

4.3.3.4  Project  Management  Plan  Updates 

Elements  of  the  project  management  plan  that  may  be  updated  include,  but  are  not  limited  to: 

• Scope  management  plan, 

• Requirements  management  plan, 

• Schedule  management  plan, 

• Cost  management  plan, 

• Quality  management  plan, 

• Process  improvement  plan, 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK®  Guide)  - Fifth  Edition 


85 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


4 - PROJECT  INTEGRATION  MANAGEMENT 


• Human  resource  management  plan, 

• Communications  management  plan, 

• Risk  management  plan, 

• Procurement  management  plan, 

• Stakeholder  management  plan,  and 

• Project  baselines. 

4.3.3.5  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Requirements  documentation, 

• Project  logs  (issues,  assumptions,  etc.), 

• Risk  register,  and 

• Stakeholder  register. 

4.4  Monitor  and  Control  Project  Work 

Monitor  and  Control  Project  Work  is  the  process  of  tracking,  reviewing,  and  reporting  the  progress  to  meet  the 
performance  objectives  defined  in  the  project  management  plan.  The  key  benefit  of  this  process  is  that  it  allows 
stakeholders  to  understand  the  current  state  of  the  project,  the  steps  taken,  and  budget,  schedule,  and  scope 
forecasts.  The  inputs,  tools  and  techniques,  and  outputs  for  this  process  are  depicted  in  Figure  4-8.  Figure  4-9 
depicts  the  data  flow  diagram  of  the  process. 
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Figure  4-8.  Monitor  and  Control  Project  Work:  Inputs,  Tools  & Techniques,  and  Outputs 
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Monitoring  is  an  aspect  of  project  management  performed  throughout  the  project.  Monitoring  includes  collecting, 
measuring,  and  distributing  performance  information,  and  assessing  measurements  and  trends  to  effect  process 
improvements.  Continuous  monitoring  gives  the  project  management  team  insight  into  the  health  of  the  project  and 
identifies  any  areas  that  may  require  special  attention.  Control  includes  determining  corrective  or  preventive  actions 
or  replanning  and  following  up  on  action  plans  to  determine  whether  the  actions  taken  resolved  the  performance 
issue.  The  Monitor  and  Control  Project  Work  process  is  concerned  with: 

• Comparing  actual  project  performance  against  the  project  management  plan; 

• Assessing  performance  to  determine  whether  any  corrective  or  preventive  actions  are  indicated,  and 
then  recommending  those  actions  as  necessary; 

• Identifying  new  risks  and  analyzing,  tracking,  and  monitoring  existing  project  risks  to  make  sure  the  risks 
are  identified,  their  status  is  reported,  and  that  appropriate  risk  response  plans  are  being  executed; 

• Maintaining  an  accurate,  timely  information  base  concerning  the  project’s  product(s)  and  their  associated 
documentation  through  project  completion; 

• Providing  information  to  support  status  reporting,  progress  measurement,  and  forecasting; 

• Providing  forecasts  to  update  current  cost  and  current  schedule  information; 

• Monitoring  implementation  of  approved  changes  as  they  occur;  and 

• Providing  appropriate  reporting  on  project  progress  and  status  to  program  management  when  the  project 
is  part  of  an  overall  program. 

4.4.1  Monitor  and  Control  Project  Work:  Inputs 

4.4.1 .1  Project  Management  Plan 

Described  in  Section  4. 2.3.1.  Monitoring  and  controlling  project  work  involves  looking  at  all  aspects  of  the 
project.  Subsidiary  plans  within  the  project  management  plan  form  the  basis  for  controlling  the  project.  Subsidiary 
plans  and  baselines  include,  but  are  not  limited  to: 
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• Scope  management  plan  (Section  5.1 .3.1 ), 

• Requirements  management  plan  (Section  5.1 .3.2), 

• Schedule  management  plan  (Section  6.1 .3.1), 

• Cost  management  plan  (Section  7.1 .3.1 ), 

• Quality  management  plan  (Section  8.1 .3.1 ), 

• Process  improvement  plan  (Section  8.1 .3.2), 

• Human  resource  management  plan  (Section  9.1 .3.1), 

• Communications  management  plan  (Section  1 0.1 .3.1 ), 

• Risk  management  plan  (Section  1 1 .1 .3.1 ), 

• Procurement  management  plan  (Section  1 2.1 .3.1 ), 

• Stakeholder  management  plan  (Section  1 3.2. 3.1 ), 

• Scope  baseline  (Section  5. 4.3.1), 

• Schedule  baseline  (Section  6.6. 3.1),  and 

• Cost  baseline  (Section  7. 3.3.1). 

4.4.1 .2  Schedule  Forecasts 

Described  in  Section  6.7. 3.2.  The  schedule  forecasts  are  derived  from  progress  against  the  schedule  baseline 
and  computed  time  estimate  to  complete  (ETC).  This  is  typically  expressed  in  terms  of  schedule  variance  (SV)  and 
schedule  performance  index  (SPI).  For  projects  not  using  earned  value  management,  variances  against  the  planned 
finish  dates  and  forecasted  finish  dates  are  provided. 

The  forecast  may  be  used  to  determine  if  the  project  is  still  within  defined  tolerance  ranges  and  identify  any 
necessary  change  requests. 

4.4.1 .3  Cost  Forecasts 

Described  in  Section  7.4. 3.2.  The  costforecasts  are  derived  from  progress  againstthe  cost  baseline  and  computed 
estimates  to  complete  (ETC).  This  is  typically  expressed  in  terms  of  cost  variance  (CV)  and  cost  performance  index 
(CPI).  An  estimate  at  completion  (EAC)  can  be  compared  to  the  budget  at  completion  (BAC)  to  see  if  the  project  is 
still  within  tolerance  ranges  or  if  a change  request  is  required.  For  projects  not  using  earned  value  management, 
variances  againstthe  planned  versus  actual  expenditures  and  forecasted  final  costs  are  provided. 
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4.4.1 .4  Validated  Changes 

Described  in  Section  8. 3.3. 2.  Approved  changes  that  result  from  the  Perform  Integrated  Change  Control  process 
require  validation  to  ensure  that  the  change  was  appropriately  implemented.  A validated  change  provides  the 
necessary  data  to  confirm  that  the  change  was  appropriately  executed. 

4.4.1 .5  Work  Performance  Information 

Work  performance  information  is  the  performance  data  collected  from  various  controlling  processes,  analyzed 
in  context,  and  integrated  based  on  relationships  across  areas.  Thus  work  performance  data  has  been  transformed 
into  work  performance  information.  Data  in  itself  cannot  be  used  in  the  decision-making  process  as  it  has  only 
out-of-context  meaning.  Work  performance  information,  however,  is  correlated  and  contextualized,  and  provides  a 
sound  foundation  for  project  decisions. 

Work  performance  information  is  circulated  through  communication  processes.  Examples  of  performance 
information  are  status  of  deliverables,  implementation  status  for  change  requests,  and  forecasted  estimates  to 
complete. 

4.4.1 .6  Enterprise  Environmental  Factors 

Described  in  Section  2.1.5.  The  enterprise  environmental  factors  that  can  influence  the  Monitor  and  Control 
Project  Work  process  include,  but  are  not  limited  to: 

• Governmental  or  industry  standards  (e.g.,  regulatory  agency  regulations,  codes  of  conduct,  product 
standards,  quality  standards,  and  workmanship  standards), 

• Organization  work  authorization  systems, 

• Stakeholder  risk  tolerances,  and 

• Project  management  information  system  (e.g.,  an  automated  tool  suite,  such  as  a scheduling  software 
tool,  a configuration  management  system,  an  information  collection  and  distribution  system,  or  web 
interfaces  to  other  online  automated  systems). 
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4.4.1 .7  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  can  influence  the  Monitor  and  Control  Project 
Work  process  include,  but  are  not  limited  to: 

• Organizational  communication  requirements; 

• Financial  controls  procedures  (e.g.,  time  reporting,  required  expenditure  and  disbursement  reviews, 
accounting  codes,  and  standard  contract  provisions); 

• Issue  and  defect  management  procedures  defining  issue  and  defect  controls,  issue  and  defect 
identification,  and  resolution  and  action  item  tracking; 

• Change  control  procedures,  including  those  for  scope,  schedule,  cost,  and  quality  variances; 

• Risk  control  procedures  including  risk  categories,  probability  definition  and  impact,  and  probability  and 
impact  matrix; 

• Process  measurement  database  used  to  make  available  measurement  data  on  processes  and  products; 
and 

• Lessons  learned  database. 

4.4.2  Monitor  and  Control  Project  Work:  Tools  and  Techniques 

4.4.2.1  Expert  Judgment 

Expert  judgment  is  used  by  the  project  management  team  to  interpret  the  information  provided  by  the  monitor 
and  control  processes.  The  project  manager,  in  collaboration  with  the  team,  determines  the  actions  required  to 
ensure  that  project  performance  matches  expectations. 

4.4.2.2  Analytical  Techniques 

Analytical  techniques  are  applied  in  project  management  to  forecast  potential  outcomes  based  on  possible 
variations  of  project  or  environmental  variables  and  their  relationships  with  other  variables.  Examples  of  analytical 
techniques  used  in  projects  are: 

• Regression  analysis, 

• Grouping  methods, 

• Causal  analysis, 
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• Root  cause  analysis, 

• Forecasting  methods  (e.g.,  time  series,  scenario  building,  simulation,  etc.), 

• Failure  mode  and  effect  analysis  (FMEA), 

• Fault  tree  analysis  (FTA), 

• Reserve  analysis, 

• Trend  analysis, 

• Earned  value  management,  and 

• Variance  analysis. 

4.4.2.3  Project  Management  Information  System 

The  project  management  information  system,  which  is  part  of  enterprise  environmental  factors,  provides  access 
to  automated  tools,  such  as  scheduling,  cost,  and  resourcing  tools,  performance  indicators,  databases,  project 
records,  and  financials  used  during  the  Monitor  and  Control  Project  Work  process. 

4.4.2.4  Meetings 

Described  in  Section  4. 3.2. 3.  Meetings  may  be  face-to-face,  virtual,  formal,  or  informal.  They  may  include 
project  team  members,  stakeholders,  and  others  involved  in  or  affected  by  the  project.  Types  of  meetings  include, 
but  are  not  limited  to,  user  groups  and  review  meetings. 

4.4.3  Monitor  and  Control  Project  Work:  Outputs 

4.4.3.1  Change  Requests 

As  a result  of  comparing  planned  results  to  actual  results,  change  requests  may  be  issued  to  expand,  adjust,  or 
reduce  project  scope,  product  scope,  or  quality  requirements  and  schedule  or  cost  baselines.  Change  requests  may 
necessitate  the  collection  and  documentation  of  new  requirements.  Changes  can  impact  the  project  management 
plan,  project  documents,  or  product  deliverables.  Changes  that  meet  the  project’s  change  control  criteria  should  go 
through  the  integrated  change  control  process  established  for  the  project.  Changes  may  include,  but  are  not  limited 
to,  the  following: 
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• Corrective  action — An  intentional  activity  that  realigns  the  performance  of  the  project  work  with  the 
project  management  plan; 

• Preventive  action — An  intentional  activity  that  ensures  the  future  performance  of  the  project  work  is 
aligned  with  the  project  management  plan;  and 

• Defect  repair — An  intentional  activity  to  modify  a nonconforming  product  or  product  component. 

4 

4.4.3.2  Work  Performance  Reports 

Work  performance  reports  are  the  physical  or  electronic  representation  of  work  performance  information 
compiled  in  project  documents,  intended  to  generate  decisions,  actions,  or  awareness.  Project  information  may  be 
communicated  verbally  from  person  to  person.  However,  in  order  to  record,  store,  and  sometimes  distribute  work 
performance  information,  a physical  or  electronic  representation  in  the  form  of  project  documents  is  required.  Work 
performance  reports  are  a subset  of  project  documents,  which  are  intended  to  create  awareness  and  generate 
decisions  or  actions.  Specific  work  performance  metrics  may  be  defined  at  the  start  of  the  project  and  included  in 
the  normal  work  performance  reports  provided  to  key  stakeholders. 

Examples  of  work  performance  reports  include  status  reports,  memos,  justifications,  information  notes, 
recommendations,  and  updates. 

4.4.3.3  Project  Management  Plan  Updates 

Changes  identified  during  the  Monitor  and  Control  Project  Work  process  may  affect  the  overall  project 
management  plan.  These  changes,  after  being  processed  through  the  appropriate  change  control  process  can  lead 
to  project  management  plan  updates.  Project  management  plan  elements  that  may  be  updated  include,  but  are 
not  limited  to: 

• Scope  management  plan  (Section  5.1 .3.1 ), 

• Requirements  management  plan  (Section  5.1 .3.2), 

• Schedule  management  plan  (Section  6.1 .3.1), 

• Cost  management  plan  (Section  7.1 .3.1 ), 

• Quality  management  plan  (Section  8.1 .3.1 ), 

• Scope  baseline  (Section  5. 4.3.1), 

• Schedule  baseline  (Section  6.6. 3.1),  and 

• Cost  baseline  (Section  7. 3.3.1). 
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4.4.3.4  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Schedule  and  cost  forecasts, 

• Work  performance  reports,  and 

• Issue  log. 


4.5  Perform  Integrated  Change  Control 

Perform  Integrated  Change  Control  is  the  process  of  reviewing  all  change  requests;  approving  changes  and 
managing  changes  to  deliverables,  organizational  process  assets,  project  documents,  and  the  project  management 
plan;  and  communicating  their  disposition.  It  reviews  all  requests  for  changes  or  modifications  to  project  documents, 
deliverables,  baselines,  or  the  project  management  plan  and  approves  or  rejects  the  changes.  The  key  benefit  of 
this  process  is  that  it  allows  for  documented  changes  within  the  project  to  be  considered  in  an  integrated  fashion 
while  reducing  project  risk,  which  often  arises  from  changes  made  without  consideration  to  the  overall  project 
objectives  or  plans.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  4-1 0.  Figure 
4-1 1 depicts  the  data  flow  diagram  of  the  process. 
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Figure  4-10.  Perform  Integrated  Change  Control:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  4-11.  Perform  Integrated  Change  Control  Data  Flow  Diagram 
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The  Perform  Integrated  Change  Control  process  is  conducted  from  project  inception  through  completion  and  is 
the  ultimate  responsibility  of  the  project  manager.  The  project  management  plan,  the  project  scope  statement,  and 
other  deliverables  are  maintained  by  carefully  and  continuously  managing  changes,  either  by  rejecting  changes 
or  by  approving  changes,  thereby  assuring  that  only  approved  changes  are  incorporated  into  a revised  baseline. 

Changes  may  be  requested  by  any  stakeholder  involved  with  the  project.  Although  changes  may  be  initiated 
verbally,  they  should  be  recorded  in  written  form  and  entered  into  the  change  management  and/or  configuration 
management  system.  Change  requests  are  subject  to  the  process  specified  in  the  change  control  and  configuration 
control  systems. Those  change  request  processes  may  require  information  on  estimated  time  impacts  and  estimated 
cost  impacts. 

Every  documented  change  request  needs  to  be  either  approved  or  rejected  by  a responsible  individual,  usually 
the  project  sponsor  or  project  manager.  The  responsible  individual  will  be  identified  in  the  project  management  plan 
or  by  organizational  procedures.  When  required,  the  Perform  Integrated  Change  Control  process  includes  a change 
control  board  (CCB),  which  is  a formally  chartered  group  responsible  for  reviewing,  evaluating,  approving,  delaying, 
or  rejecting  changes  to  the  project,  and  for  recording  and  communicating  such  decisions.  Approved  change 
requests  can  require  new  or  revised  cost  estimates,  activity  sequences,  schedule  dates,  resource  requirements, 
and  analysis  of  risk  response  alternatives.  These  changes  can  require  adjustments  to  the  project  management 
plan  and  other  project  documents.  The  applied  level  of  change  control  is  dependent  upon  the  application  area, 
complexity  of  the  specific  project,  contract  requirements,  and  the  context  and  environment  in  which  the  project  is 
performed.  Customer  or  sponsor  approval  may  be  required  for  certain  change  requests  after  CCB  approval,  unless 
they  are  part  of  the  CCB. 

Configuration  control  is  focused  on  the  specification  of  both  the  deliverables  and  the  processes;  while  change 
control  is  focused  on  identifying,  documenting,  and  approving  or  rejecting  changes  to  the  project  documents, 
deliverables,  or  baselines. 

Some  of  the  configuration  management  activities  included  in  the  Perform  Integrated  Change  Control  process 
are  as  follows: 

• Configuration  identification.  Identification  and  selection  of  a configuration  item  to  provide  the  basis  for 
which  the  product  configuration  is  defined  and  verified,  products  and  documents  are  labeled,  changes 
are  managed,  and  accountability  is  maintained. 
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• Configuration  status  accounting.  Information  is  recorded  and  reported  as  to  when  appropriate 
data  about  the  configuration  item  should  be  provided.  This  information  includes  a listing  of  approved 
configuration  identification,  status  of  proposed  changes  to  the  configuration,  and  the  implementation 
status  of  approved  changes. 

• Configuration  verification  and  audit.  Configuration  verification  and  configuration  audits  ensure  the 
composition  of  a project’s  configuration  items  is  correct  and  that  corresponding  changes  are  registered, 
assessed,  approved,  tracked,  and  correctly  implemented.  This  ensures  the  functional  requirements 
defined  in  the  configuration  documentation  have  been  met. 

4.5.1  Perform  Integrated  Change  Control:  Inputs 

4.5.1 .1  Project  Management  Plan 

Described  in  Section  4.2. 3.1.  Elements  of  the  project  management  plan  that  may  be  used  include,  but  are  not 
limited  to: 


• Scope  management  plan,  which  contains  the  procedures  for  scope  changes; 

• Scope  baseline,  which  provides  product  definition;  and 

• Change  management  plan,  which  provides  the  direction  for  managing  the  change  control  process  and 
documents  the  formal  change  control  board  (CCB). 

Changes  are  documented  and  updated  within  the  project  management  plan  as  part  of  the  change  and 
configuration  management  processes. 

4.5.1 .2  Work  Performance  Reports 

Described  in  Section  4. 4.3. 2.  Work  performance  reports  of  particular  interest  to  the  Perform  Integrated  Change 
Control  process  include  resource  availability,  schedule  and  cost  data,  and  earned  value  management  (EVM)  reports, 
burnup  or  burndown  charts. 

4.5.1 .3  Change  Requests 

All  of  the  Monitoring  and  Controlling  processes  and  many  of  the  Executing  processes  produce  change  requests 
as  an  output.  Change  requests  may  include  corrective  action,  preventive  action,  and  defect  repairs.  However, 
corrective  and  preventive  actions  do  not  normally  affect  the  project  baselines — only  the  performance  against  the 
baselines. 
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4.5.1 .4  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  The  following  enterprise  environmental  factor  can  influence  the  Perform  Integrated 
Change  Control  process:  project  management  information  system.  The  project  management  information  system 
may  include  the  scheduling  software  tool,  a configuration  management  system,  an  information  collection  and 
distribution  system,  or  web  interfaces  to  other  online  automated  systems. 

4.5.1 .5  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  can  influence  the  Perform  Integrated  Change 
Control  process  include,  but  are  not  limited  to: 

• Change  control  procedures,  including  the  steps  by  which  official  organization  standards,  policies,  plans, 
and  other  project  documents  will  be  modified,  and  how  any  changes  will  be  approved,  validated,  and 
implemented; 

• Procedures  for  approving  and  issuing  change  authorizations; 

• Process  measurement  database  used  to  collect  and  make  available  measurement  data  on  processes 
and  products; 

• Project  documents  (e.g.,  scope,  cost,  and  schedule  baselines,  project  calendars,  project  schedule  network 
diagrams,  risk  registers,  planned  response  actions,  and  defined  risk  impact);  and 

• Configuration  management  knowledge  base  containing  the  versions  and  baselines  of  all  official 
organization  standards,  policies,  procedures,  and  any  project  documents. 

4.5.2  Perform  Integrated  Change  Control:  Tools  and  Techniques 

4.5.2.1  Expert  Judgment 

In  addition  to  the  project  management  team’s  expert  judgment,  stakeholders  may  be  asked  to  provide  their 
expertise  and  may  be  asked  to  sit  on  the  change  control  board  (CCB).  Such  judgment  and  expertise  are  applied  to 
any  technical  and  management  details  during  this  process  and  may  be  provided  by  various  sources,  for  example: 
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• Consultants, 

• Stakeholders,  including  customers  or  sponsors, 

• Professional  and  technical  associations, 

• Industry  groups, 

• Subject  matter  experts  (SMEs),  and 

• Project  management  office  (PMO). 

4.5. 2.2  Meetings 

In  this  case,  these  meetings  are  usually  referred  to  as  change  control  meetings.  When  needed  for  the  project,  a 
change  control  board  (CCB)  is  responsible  for  meeting  and  reviewing  the  change  requests  and  approving,  rejecting, 
or  other  disposition  of  those  changes.  The  CCB  may  also  review  configuration  management  activities.  The  roles  and 
responsibilities  of  these  boards  are  clearly  defined  and  agreed  upon  by  appropriate  stakeholders  and  documented 
in  the  change  management  plan.  CCB  decisions  are  documented  and  communicated  to  the  stakeholders  for 
information  and  follow-up  actions. 

4.5.2.3  Change  Control  Tools 

In  order  to  facilitate  configuration  and  change  management,  manual  or  automated  tools  may  be  used.  Tool 
selection  should  be  based  on  the  needs  of  the  project  stakeholders  including  organizational  and  environmental 
considerations  and/or  constraints. 

Tools  are  used  to  manage  the  change  requests  and  the  resulting  decisions.  Additional  considerations  should 
be  made  for  communication  to  assist  the  CCB  members  in  their  duties  as  well  as  distribute  the  decisions  to  the 
appropriate  stakeholders. 

4.5.3  Perform  Integrated  Change  Control:  Outputs 
4.5.3.1  Approved  Change  Requests 

Change  requests  are  processed  according  to  the  change  control  system  by  the  project  manager,  CCB,  or  by  an 
assigned  team  member.  Approved  change  requests  will  be  implemented  through  the  Direct  and  Manage  Project 
Work  process.  The  disposition  of  all  change  requests,  approved  or  not,  will  be  updated  in  the  change  log  as  part  of 
updates  to  the  project  documents. 
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4.5.3.2  Change  Log 

A change  log  is  used  to  document  changes  that  occur  during  a project.  These  changes  and  their  impact  to 
the  project  in  terms  of  time,  cost,  and  risk,  are  communicated  to  the  appropriate  stakeholders.  Rejected  change 
requests  are  also  captured  in  the  change  log. 

4.5.3.3  Project  Management  Plan  Updates 

Elements  of  the  project  management  plan  that  may  be  updated  include,  but  are  not  limited  to: 

• Any  subsidiary  plans,  and 

• Baselines  that  are  subject  to  the  formal  change  control  process. 

Changes  to  baselines  should  only  show  the  changes  from  the  current  time  forward.  Past  performance  may  not 
be  changed.  This  protects  the  integrity  of  the  baselines  and  the  historical  data  of  past  performance. 

4.5.3.4  Project  Documents  Updates 

Project  documents  that  may  be  updated  as  a result  of  the  Perform  Integrated  Change  Control  process  include 
all  documents  specified  as  being  subject  to  the  project’s  formal  change  control  process. 


4.6  Close  Project  or  Phase 

Close  Project  or  Phase  is  the  process  of  finalizing  all  activities  across  all  of  the  Project  Management  Process 
Groups  to  formally  complete  the  project  or  phase.  The  key  benefit  of  this  process  is  that  it  provides  lessons  learned, 
the  formal  ending  of  project  work,  and  the  release  of  organization  resources  to  pursue  new  endeavors.  The  inputs, 
tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  4-12.  Figure  4-13  depicts  the  data  flow 
diagram  of  the  process. 


Inputs 
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.2  Accepted  deliverables 
.3  Organizational  process 
assets 

V ) 
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Figure  4-12.  Close  Project  or  Phase:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  4-13.  Close  Project  or  Phase  Data  Flow  Diagram 


When  closing  the  project,  the  project  manager  reviews  all  prior  information  from  the  previous  phase  closures  to 
ensure  that  all  project  work  is  completed  and  that  the  project  has  met  its  objectives.  Since  project  scope  is  measured 
against  the  project  management  plan,  the  project  manager  reviews  the  scope  baseline  to  ensure  completion  before 
considering  the  project  closed.  The  Close  Project  or  Phase  process  also  establishes  the  procedures  to  investigate 
and  document  the  reasons  for  actions  taken  if  a project  is  terminated  before  completion.  In  order  to  successfully 
achieve  this,  the  project  manager  needs  to  engage  all  the  proper  stakeholders  in  the  process. 

This  includes  all  planned  activities  necessary  for  administrative  closure  of  the  project  or  phase,  including  step- 
by-step  methodologies  that  address: 

• Actions  and  activities  necessary  to  satisfy  completion  or  exit  criteria  for  the  phase  or  project; 

• Actions  and  activities  necessary  to  transfer  the  project’s  products,  services,  or  results  to  the  next  phase 
or  to  production  and/or  operations;  and 

• Activities  needed  to  collect  project  or  phase  records,  audit  project  success  or  failure,  gather  lessons 
learned  and  archive  project  information  for  future  use  by  the  organization. 
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4.6.1  Close  Project  or  Phase:  Inputs 

4.6.1 .1  Project  Management  Plan 

Described  in  Section  4.2. 3.1 . The  project  management  plan  becomes  the  agreement  between  the  project 
manager  and  project  sponsor,  defining  what  constitutes  project  completion. 

4.6.1 .2  Accepted  Deliverables 

Described  in  Section  5.5.  Accepted  deliverables  may  include  approved  product  specifications,  delivery 
receipts,  and  work  performance  documents.  Partial  or  interim  deliverables  may  also  be  included  for  phased  or 
cancelled  projects. 

4.6.1 .3  Organizational  Process  Assets 

Described  in  Section  2.1.4.  The  organizational  process  assets  that  can  influence  the  Close  Project  or  Phase 
process  include,  but  are  not  limited  to: 

• Project  or  phase  closure  guidelines  or  requirements  (e.g.,  administrative  procedures,  project  audits, 
project  evaluations,  and  transition  criteria);  and 

• Historical  information  and  lessons  learned  knowledge  base  (e.g.,  project  records  and  documents,  all 
project  closure  information  and  documentation,  information  about  both  the  results  of  previous  project 
selection  decisions  and  previous  project  performance  information,  and  information  from  risk  management 
activities). 

4.6.2  Close  Project  or  Phase:  Tools  and  Techniques 

4.6.2.1  Expert  Judgment 

Expert  judgment  is  applied  when  performing  administrative  closure  activities.  These  experts  ensure  the  project 
or  phase  closure  is  performed  to  the  appropriate  standards.  Expertise  is  available  from  many  sources,  including 
but  not  limited  to 

• Other  project  managers  within  the  organization, 

• Project  management  office  (PMO),  and 

• Professional  and  technical  associations. 
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4.6.2.2  Analytical  Techniques 

Described  in  Section  4.4. 2.2.  Examples  of  analytical  techniques  used  in  project  closeout  are: 

• Regression  analysis,  and 

• Trend  analysis. 

4.6.2.3  Meetings 

Described  in  Section  4.3. 2.3.  Meetings  may  be  face-to-face,  virtual,  formal,  or  informal. This  may  include  project 
team  members  and  other  stakeholders,  involved  in  or  affected  by  the  project.  Types  of  meetings  include,  but  are  not 
limited  to  lessons  learned,  closeout,  user  group,  and  review  meetings. 

4.6.3  Close  Project  or  Phase:  Outputs 

4.6.3.1  Final  Product,  Service,  or  Result  Transition 

This  output  refers  to  the  transition  of  the  final  product,  service,  or  result  that  the  project  was  authorized  to 
produce  (or  in  the  case  of  phase  closure,  the  intermediate  product,  service,  or  result  of  that  phase). 

4.6.3.2  Organizational  Process  Assets  Updates 

The  organizational  process  assets  that  are  updated  as  a result  of  the  Close  Project  or  Phase  process  include, 
but  are  not  limited  to: 
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• Project  files — Documentation  resulting  from  the  project’s  activities,  for  example,  project  management 
plan;  scope,  cost,  schedule,  and  project  calendars;  risk  registers  and  other  registers;  change  management 
documentation;  planned  risk  response  actions;  and  risk  impact. 

• Project  or  phase  closure  documents — Project  or  phase  closure  documents,  consisting  of  formal 
documentation  that  indicates  completion  of  the  project  or  phase  and  the  transfer  of  the  completed 
project  or  phase  deliverables  to  others,  such  as  an  operations  group  or  to  the  next  phase.  During  project 
closure,  the  project  manager  reviews  prior  phase  documentation,  customer  acceptance  documentation 
from  the  Validate  Scope  process  (Section  5.4),  and  the  contract  (if  applicable),  to  ensure  that  all  project 
requirements  are  completed  prior  to  finalizing  the  closure  of  the  project.  If  the  project  was  terminated 
prior  to  completion,  the  formal  documentation  indicates  why  the  project  was  terminated  and  formalizes 
the  procedures  for  the  transfer  of  the  finished  and  unfinished  deliverables  of  the  cancelled  project  to 
others. 

• Historical  information — Historical  information  and  lessons  learned  information  are  transferred  to  the 
lessons  learned  knowledge  base  for  use  by  future  projects  or  phases.  This  can  include  information  on 
issues  and  risks  as  well  as  techniques  that  worked  well  that  can  be  applied  to  future  projects. 
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PROJECT  SCOPE  MANAGEMENT 


Project  Scope  Management  includes  the  processes  required  to  ensure  that  the  project  includes  all  the  work 
required,  and  only  the  work  required,  to  complete  the  project  successfully.  Managing  the  project  scope  is  primarily 
concerned  with  defining  and  controlling  what  is  and  is  not  included  in  the  project. 

Figure  5-1  provides  an  overview  of  the  Project  Scope  Management  processes,  which  include  the  following: 

5.1  Plan  Scope  Management — The  process  of  creating  a scope  management  plan  that  documents  how 
the  project  scope  will  be  defined,  validated,  and  controlled. 

5.2  Collect  Requirements — The  process  of  determining,  documenting,  and  managing  stakeholder  needs 
and  requirements  to  meet  project  objectives. 

5.3  Define  Scope — The  process  of  developing  a detailed  description  of  the  project  and  product. 

5.4  Create  WBS — The  process  of  subdividing  project  deliverables  and  project  work  into  smaller,  more 
manageable  components. 

5.5  Validate  Scope — The  process  of  formalizing  acceptance  of  the  completed  project  deliverables. 

5.6  Control  Scope — The  process  of  monitoring  the  status  of  the  project  and  product  scope  and  managing 
changes  to  the  scope  baseline. 

These  processes  interact  with  each  other  and  with  processes  in  other  Knowledge  Areas  as  described  in  detail 
in  Section  3 and  Annex  A1. 

In  the  project  context,  the  term  scope  can  refer  to: 

• Product  scope.  The  features  and  functions  that  characterize  a product,  service,  or  result;  and/or 

• Project  scope.  The  work  performed  to  deliver  a product,  service,  or  result  with  the  specified  features  and 
functions.  The  term  project  scope  is  sometimes  viewed  as  including  product  scope. 

The  processes  used  to  manage  project  scope,  as  well  as  the  supporting  tools  and  techniques,  can  vary 
by  project.  The  scope  baseline  for  the  project  is  the  approved  version  of  the  project  scope  statement,  work 
breakdown  structure  (WBS),  and  its  associated  WBS  dictionary.  A baseline  can  be  changed  only  through  formal 
change  control  procedures  and  is  used  as  a basis  for  comparison  while  performing  Validate  Scope  and  Control 
Scope  processes  as  well  as  other  controlling  processes. 
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Completion  of  the  project  scope  is  measured  against  the  project  management  plan  (Section  4. 2.3.1).  Completion 
of  the  product  scope  is  measured  against  the  product  requirements  (Section  5.2).  The  Project  Scope  Management 
processes  need  to  be  well  integrated  with  the  other  Knowledge  Area  processes,  so  that  the  work  of  the  project  will 
result  in  delivery  of  the  specified  product  scope. 
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Figure  5-1 . Project  Scope  Management  Overview 
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5.1  Plan  Scope  Management 

Plan  Scope  Management  is  the  process  of  creating  a scope  management  plan  that  documents  how  the  project 
scope  will  be  defined,  validated,  and  controlled.  The  key  benefit  of  this  process  is  that  it  provides  guidance  and 
direction  on  how  scope  will  be  managed  throughout  the  project.  The  inputs,  tools  and  techniques,  and  outputs  of 
this  process  are  depicted  in  Figure  5-2.  Figure  5-3  depicts  the  data  flow  diagram  of  the  process. 
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Figure  5-2.  Plan  Scope  Management:  Inputs,  Tools  & Techniques,  and  Outputs 


Figure  5-3.  Plan  Scope  Management  Data  Flow  Diagram 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK®  Guide)  - Fifth  Edition 


107 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


5 - PROJECT  SCOPE  MANAGEMENT 


The  scope  management  plan  is  a component  of  the  project  or  program  management  plan  that  describes  how  the 
scope  will  be  defined,  developed,  monitored,  controlled,  and  verified.  The  development  of  the  scope  management 
plan  and  the  detailing  of  the  project  scope  begin  with  the  analysis  of  information  contained  in  the  project  charter 
(Section  4.1 .3.1),  the  latest  approved  subsidiary  plans  of  the  project  management  plan  (Section  4. 2.3.1),  historical 
information  contained  in  the  organizational  process  assets  (Section  2.1.4),  and  any  other  relevant  enterprise 
environmental  factors  (Section  2.1 .5).  This  plan  helps  reduce  the  risk  of  project  scope  creep. 

5.1.1  Plan  Scope  Management:  Inputs 

5.1 .1 .1  Project  Management  Plan 

Described  in  Section  4. 2.3.1 . Approved  subsidiary  plans  of  the  project  management  plan  are  used  to  create  the 
scope  management  plan  and  influence  the  approach  taken  for  planning  scope  and  managing  project  scope. 

5.1 .1 .2  Project  Charter 

Described  in  Section  4.1 .3.1 . The  project  charter  is  used  to  provide  the  project  context  needed  to  plan  the  scope 
management  processes.  It  provides  the  high-level  project  description  and  product  characteristics  from  the  project 
statement  of  work. 

5.1 .1 .3  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  The  enterprise  environmental  factors  that  can  influence  the  Plan  Scope  Management 
process  include,  but  are  not  limited  to: 

• Organization’s  culture, 

• Infrastructure, 

• Personnel  administration,  and 

• Marketplace  conditions. 
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5.1 .1 .4  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  can  influence  the  Plan  Scope  Management 
process  include,  but  are  not  limited  to: 

• Policies  and  procedures,  and 

• Historical  information  and  lessons  learned  knowledge  base. 

5.1.2  Plan  Scope  Management:  Tools  and  Techniques 

5.1 .2.1  Expert  Judgment 

Expert  judgment  refers  to  input  received  from  knowledgeable  and  experienced  parties.  Expertise  may  be 
provided  by  any  group  or  person  with  specialized  education,  knowledge,  skill,  experience,  or  training  in  developing 
scope  management  plans. 

5.1 .2.2  Meetings 

Project  teams  may  attend  project  meetings  to  develop  the  scope  management  plan.  Attendees  at  these 
meetings  may  include  the  project  manager,  the  project  sponsor,  selected  project  team  members,  selected 
stakeholders,  anyone  with  responsibility  for  any  of  the  scope  management  processes,  and  others  as  needed. 

5.1.3  Plan  Scope  Management:  Outputs 
5.1 .3.1  Scope  Management  Plan 

The  scope  management  plan  is  a component  of  the  project  or  program  management  plan  that  describes  how  the 
scope  will  be  defined,  developed,  monitored,  controlled,  and  verified.  The  scope  management  plan  is  a major  input 
into  the  Develop  Project  Management  Plan  process,  and  the  other  scope  management  processes.  The  components 
of  a scope  management  plan  include: 
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• Process  for  preparing  a detailed  project  scope  statement; 

• Process  that  enables  the  creation  of  the  WBS  from  the  detailed  project  scope  statement; 

• Process  that  establishes  how  the  WBS  will  be  maintained  and  approved; 

• Process  that  specifies  how  formal  acceptance  of  the  completed  project  deliverables  will  be  obtained;  and 

• Process  to  control  how  requests  for  changes  to  the  detailed  project  scope  statement  will  be  processed. 
This  process  is  directly  linked  to  the  Perform  Integrated  Change  Control  process  (Section  4.5). 

The  scope  management  plan  can  be  formal  or  informal,  broadly  framed  or  highly  detailed,  based  on  the  needs 
of  the  project. 

5.1 .3.2  Requirements  Management  Plan 

The  requirements  management  plan  is  a component  of  the  project  management  plan  that  describes  how 
requirements  will  be  analyzed,  documented,  and  managed.  The  phase-to-phase  relationship,  described  in 
Section  2. 4.2.1,  strongly  influences  how  requirements  are  managed.  The  project  manager  chooses  the  most 
effective  relationship  for  the  project  and  documents  this  approach  in  the  requirements  management  plan.  Many  of 
the  requirements  management  plan  components  are  based  on  that  relationship. 

Components  of  the  requirements  management  plan  can  include,  but  are  not  limited  to: 

• How  requirements  activities  will  be  planned,  tracked,  and  reported; 

• Configuration  management  activities  such  as:  how  changes  to  the  product  will  be  initiated,  how  impacts 
will  be  analyzed,  how  they  will  be  traced,  tracked,  and  reported,  as  well  as  the  authorization  levels 
required  to  approve  these  changes; 

• Requirements  prioritization  process; 

• Product  metrics  that  will  be  used  and  the  rationale  for  using  them;  and 

• Traceability  structure  to  reflect  which  requirement  attributes  will  be  captured  on  the  traceability  matrix. 


5.2  Collect  Requirements 

Collect  Requirements  is  the  process  of  determining,  documenting,  and  managing  stakeholder  needs  and 
requirements  to  meet  project  objectives.  The  key  benefit  of  this  process  is  that  it  provides  the  basis  for  defining  and 
managing  the  project  scope  including  product  scope.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process 
are  depicted  in  Figure  5-4.  Figure  5-5  depicts  the  data  flow  diagram  of  the  process. 
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Figure  5-4.  Collect  Requirements:  Inputs,  Tools  & Techniques,  and  Outputs 


Project  Scope  Management 


Figure  5-5.  Collect  Requirements  Data  Flow  Diagram 
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The  project’s  success  is  directly  influenced  by  active  stakeholder  involvement  in  the  discovery  and  decomposition 
of  needs  into  requirements  and  by  the  care  taken  in  determining,  documenting,  and  managing  the  requirements 
of  the  product,  service,  or  result  of  the  project.  Requirements  include  conditions  or  capabilities  that  are  to  be 
met  by  the  project  or  present  in  the  product,  service,  or  result  to  satisfy  an  agreement  or  other  formally  imposed 
specification.  Requirements  include  the  quantified  and  documented  needs  and  expectations  of  the  sponsor, 
customer,  and  other  stakeholders.  These  requirements  need  to  be  elicited,  analyzed,  and  recorded  in  enough  detail 
to  be  included  in  the  scope  baseline  and  to  be  measured  once  project  execution  begins.  Requirements  become 
the  foundation  of  the  WBS.  Cost,  schedule,  quality  planning,  and  sometimes  procurement  are  all  based  upon 
these  requirements.  The  development  of  requirements  begins  with  an  analysis  of  the  information  contained  in  the 
project  charter  (Section  4.1 .3.1 ),  the  stakeholder  register  (Section  1 3.1 .3.1 ) and  the  stakeholder  management  plan 
(Section  13.2.3.1). 

Many  organizations  categorize  requirements  into  different  types,  such  as  business  and  technical  solutions,  the 
former  referring  to  stakeholder  needs  and  the  latter  as  to  how  those  needs  will  be  implemented.  Requirements  can 
be  grouped  into  classifications  allowing  for  further  refinement  and  detail  as  the  requirements  are  elaborated.  These 
classifications  include: 

• Business  requirements,  which  describe  the  higher-level  needs  of  the  organization  as  a whole,  such  as  the 
business  issues  or  opportunities,  and  reasons  why  a project  has  been  undertaken. 

• Stakeholder  requirements,  which  describe  needs  of  a stakeholder  or  stakeholder  group. 

• Solution  requirements,  which  describe  features,  functions,  and  characteristics  of  the  product,  service, 
or  result  that  will  meet  the  business  and  stakeholder  requirements.  Solution  requirements  are  further 
grouped  into  functional  and  nonfunctional  requirements: 

o Functional  requirements  describe  the  behaviors  of  the  product.  Examples  include  processes, 
data,  and  interactions  with  the  product. 

o Nonfunctional  requirements  supplementfunctional  requirements  and  describe  the  environmental 
conditions  or  qualities  required  for  the  product  to  be  effective.  Examples  include:  reliability, 
security,  performance,  safety,  level  of  service,  supportability,  retention/purge,  etc. 

• Transition  requirements  describe  temporary  capabilities,  such  as  data  conversion  and  training 
requirements,  needed  to  transition  from  the  current  “as-is”  state  to  the  future  “to-be”  state. 

• Project  requirements,  which  describe  the  actions,  processes,  or  other  conditions  the  project  needs 
to  meet. 

• Quality  requirements,  which  capture  any  condition  or  criteria  needed  to  validate  the  successful  completion 
of  a project  deliverable  or  fulfillment  of  other  project  requirements. 
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5.2.1  Collect  Requirements:  Inputs 

5.2.1 .1  Scope  Management  Plan 

Described  in  Section  5.1 .3.1  .The  scope  management  plan  provides  clarity  as  to  how  project  teams  will  determine 
which  type  of  requirements  need  to  be  collected  for  the  project. 

5.2.1 .2  Requirements  Management  Plan  5 

Described  in  Section  5. 1.3. 2.  The  requirements  management  plan  provides  the  processes  that  will  be  used 
throughout  the  Collect  Requirements  process  to  define  and  document  the  stakeholder  needs. 

5.2.1 .3  Stakeholder  Management  Plan 

Described  in  Section  13.2.3.1.  The  stakeholder  management  plan  is  used  to  understand  stakeholder 
communication  requirements  and  the  level  of  stakeholder  engagement  in  order  to  assess  and  adapt  to  the  level  of 
stakeholder  participation  in  requirements  activities. 

5.2.1 .4  Project  Charter 

Described  in  Section  4. 1.3.1.  The  project  charter  is  used  to  provide  the  high-level  description  of  the  product, 
service,  or  result  of  the  project  so  that  detailed  requirements  can  be  developed. 

5.2.1 .5  Stakeholder  Register 

Described  in  Section  13.1.3.1.  The  stakeholder  register  is  used  to  identify  stakeholders  who  can  provide 
information  on  the  requirements.  The  stakeholder  register  also  captures  major  requirements  and  main  expectations 
stakeholders  may  have  for  the  project. 
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5.2.2  Collect  Requirements:  Tools  and  Techniques 

5.2.2.1  Interviews 

An  interview  is  a formal  or  informal  approach  to  elicit  information  from  stakeholders  by  talking  to  them  directly. 
It  is  typically  performed  by  asking  prepared  and  spontaneous  questions  and  recording  the  responses.  Interviews 
are  often  conducted  on  an  individual  basis  between  an  interviewer  and  an  interviewee,  but  may  involve  multiple 
interviewers  and/or  multiple  interviewees.  Interviewing  experienced  project  participants,  sponsors  and  other 
executives,  and  subject  matter  experts  can  aid  in  identifying  and  defining  the  features  and  functions  of  the  desired 
product  deliverables.  Interviews  are  also  useful  for  obtaining  confidential  information. 

5.2.2.2  Focus  Groups 

Focus  groups  bring  together  prequalified  stakeholders  and  subject  matter  experts  to  learn  about  their 
expectations  and  attitudes  about  a proposed  product,  service,  or  result.  A trained  moderator  guides  the  group 
through  an  interactive  discussion,  designed  to  be  more  conversational  than  a one-on-one  interview. 

5.2.2.3  Facilitated  Workshops 

Facilitated  workshops  are  focused  sessions  that  bring  key  stakeholders  together  to  define  product  requirements. 
Workshops  are  considered  a primary  technique  for  quickly  defining  cross-functional  requirements  and  reconciling 
stakeholder  differences.  Because  of  their  interactive  group  nature,  well-facilitated  sessions  can  build  trust,  foster 
relationships,  and  improve  communication  among  the  participants,  which  can  lead  to  increased  stakeholder 
consensus.  In  addition,  issues  can  be  discovered  earlier  and  resolved  more  quickly  than  in  individual  sessions. 

For  example,  facilitated  workshops  called  joint  application  design/development  (JAD)  sessions  are  used  in  the 
software  development  industry.  These  facilitated  sessions  focus  on  bringing  business  subject  matter  experts  and 
the  development  team  together  to  improve  the  software  development  process.  In  the  manufacturing  industry,  quality 
function  deployment  (QFD)  is  another  example  of  a facilitated  workshop  technique  that  helps  determine  critical 
characteristics  for  new  product  development.  QFD  starts  by  collecting  customer  needs,  also  known  as  voice  of  the 
customer  (VOC).  These  needs  are  then  objectively  sorted  and  prioritized,  and  goals  are  set  for  achieving  them.  User 
stories,  which  are  short,  textual  descriptions  of  required  functionality,  are  often  developed  during  a requirements 
workshop.  User  stories  describe  the  stakeholder  who  benefits  from  the  feature  (role),  what  the  stakeholder  needs  to 
accomplish  (goal),  and  the  benefit  to  the  stakeholder  (motivation).  User  stories  are  widely  used  with  agile  methods. 
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5.2.2.4  Group  Creativity  Techniques 

Several  group  activities  can  be  organized  to  identify  project  and  product  requirements.  Some  of  the  group 
creativity  techniques  that  can  be  used  are: 

• Brainstorming.  A technique  used  to  generate  and  collect  multiple  ideas  related  to  project  and  product 
requirements.  Although  brainstorming  by  itself  does  not  include  voting  or  prioritization,  it  is  often  used 
with  other  group  creativity  techniques  that  do. 

• Nominal  group  technique.  A technique  that  enhances  brainstorming  with  a voting  process  used  to  rank 
the  most  useful  ideas  for  further  brainstorming  or  for  prioritization. 

• Idea/mind  mapping.  A technique  in  which  ideas  created  through  individual  brainstorming  sessions  are 
consolidated  into  a single  map  to  reflect  commonality  and  differences  in  understanding,  and  generate 
new  ideas. 

• Affinity  diagram.  A technique  that  allows  large  numbers  of  ideas  to  be  classified  into  groups  for  review 
and  analysis. 

• Multicriteria  decision  analysis.  A technique  that  utilizes  a decision  matrix  to  provide  a systematic 
analytical  approach  for  establishing  criteria,  such  as  risk  levels,  uncertainty,  and  valuation,  to  evaluate 
and  rank  many  ideas. 

5.2.2.5  Group  Decision-Making  Techniques 

A group  decision-making  technique  is  an  assessment  process  having  multiple  alternatives  with  an  expected 
outcome  in  the  form  of  future  actions.  These  techniques  can  be  used  to  generate,  classify,  and  prioritize  product 
requirements. 

There  are  various  methods  of  reaching  a group  decision,  such  as: 

• Unanimity.  A decision  that  is  reached  whereby  everyone  agrees  on  a single  course  of  action.  One  way  to 
reach  unanimity  is  the  Delphi  technique,  in  which  a selected  group  of  experts  answers  questionnaires  and 
provides  feedback  regarding  the  responses  from  each  round  of  requirements  gathering.  The  responses 
are  only  available  to  the  facilitator  to  maintain  anonymity. 

• Majority.  A decision  that  is  reached  with  support  obtained  from  more  than  50  % of  the  members  of  the 
group.  Having  a group  size  with  an  uneven  number  of  participants  can  ensure  that  a decision  will  be 
reached,  rather  than  resulting  in  a tie. 

• Plurality.  A decision  that  is  reached  whereby  the  largest  block  in  a group  decides,  even  if  a majority  is 
not  achieved.  This  method  is  generally  used  when  the  number  of  options  nominated  is  more  than  two. 

• Dictatorship.  In  this  method,  one  individual  makes  the  decision  for  the  group. 
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All  of  these  group  decision-making  techniques  can  be  applied  to  the  group  creativity  techniques  used  in  the 
Collect  Requirements  process. 

5.2.2.6  Questionnaires  and  Surveys 

Questionnaires  and  surveys  are  written  sets  of  questions  designed  to  quickly  accumulate  information  from  a 
large  number  of  respondents.  Questionnaires  and/or  surveys  are  most  appropriate  with  varied  audiences,  when 
a quick  turnaround  is  needed,  when  respondents  are  geographically  dispersed,  and  where  statistical  analysis  is 
appropriate. 

5.2.27  Observations 

Observations  provide  a direct  way  of  viewing  individuals  in  their  environment  and  how  they  perform  their  jobs  or 
tasks  and  carry  out  processes.  It  is  particularly  helpful  for  detailed  processes  when  the  people  that  use  the  product 
have  difficulty  or  are  reluctant  to  articulate  their  requirements.  Observation  is  also  known  as  “job  shadowing.” 
It  is  usually  done  externally  by  an  observer  viewing  a business  expert  performing  a job.  It  can  also  be  done  by 
a “participant  observer”  who  actually  performs  a process  or  procedure  to  experience  how  it  is  done  to  uncover 
hidden  requirements. 

5.2.2.8  Prototypes 

Prototyping  is  a method  of  obtaining  early  feedback  on  requirements  by  providing  a working  model  of  the 
expected  product  before  actually  building  it.  Since  a prototype  is  tangible,  it  allows  stakeholders  to  experiment 
with  a model  of  the  final  product  rather  than  being  limited  to  discussing  abstract  representations  of  their 
requirements.  Prototypes  support  the  concept  of  progressive  elaboration  in  iterative  cycles  of  mock-up  creation, 
user  experimentation,  feedback  generation,  and  prototype  revision.  When  enough  feedback  cycles  have  been 
performed,  the  requirements  obtained  from  the  prototype  are  sufficiently  complete  to  move  to  a design  or  build 
phase.  Storyboarding  is  a prototyping  technique  showing  sequence  or  navigation  through  a series  of  images  or 
illustrations.  Storyboards  are  used  on  a variety  of  projects  in  a variety  of  industries,  such  as  film,  advertising, 
instructional  design,  and  on  agile  and  other  software  development  projects.  In  software  development,  storyboards 
use  mock-ups  to  show  navigation  paths  through  webpages,  screens,  or  other  user  interfaces. 

5.2.2.9  Benchmarking 

Benchmarking  involves  comparing  actual  or  planned  practices,  such  as  processes  and  operations,  to  those 
of  comparable  organizations  to  identify  best  practices,  generate  ideas  for  improvement,  and  provide  a basis  for 
measuring  performance.  The  organizations  compared  during  benchmarking  can  be  internal  or  external. 
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5.2.2.10  Context  Diagrams 

The  context  diagram  is  an  example  of  a scope  model.  Context  diagrams  visually  depict  the  product  scope  by 
showing  a business  system  (process,  equipment,  computer  system,  etc.),  and  how  people  and  other  systems 
(actors)  interact  with  it.  Context  diagrams  show  inputs  to  the  business  system,  the  actor(s)  providing  the  input,  the 
outputs  from  the  business  system,  and  the  actor(s)  receiving  the  output. 

5.2.2.11  Document  Analysis 

Document  analysis  is  used  to  elicit  requirements  by  analyzing  existing  documentation  and  identifying 
information  relevant  to  the  requirements.  There  are  a wide  range  of  documents  that  may  be  analyzed  to  help  elicit 
relevant  requirements.  Examples  of  documents  that  may  be  analyzed  include,  but  are  not  limited  to:  business  plans, 
marketing  literature,  agreements,  requests  for  proposal,  current  process  flows,  logical  data  models,  business  rules 
repositories,  application  software  documentation,  business  process  or  interface  documentation,  use  cases,  other 
requirements  documentation,  problem/issue  logs,  policies,  procedures,  and  regulatory  documentation  such  as 
laws,  codes,  or  ordinances,  etc. 

5.2.3  Collect  Requirements:  Outputs 
5.2.3.1  Requirements  Documentation 

Requirements  documentation  describes  how  individual  requirements  meet  the  business  need  for  the  project. 
Requirements  may  start  out  at  a high  level  and  become  progressively  more  detailed  as  more  about  the  requirements 
is  known.  Before  being  baselined,  requirements  need  to  be  unambiguous  (measurable  and  testable),  traceable, 
complete,  consistent,  and  acceptable  to  key  stakeholders.  The  format  of  a requirements  document  may  range  from 
a simple  document  listing  all  the  requirements  categorized  by  stakeholder  and  priority,  to  more  elaborate  forms 
containing  an  executive  summary,  detailed  descriptions,  and  attachments. 

Components  of  requirements  documentation  can  include,  but,  are  not  limited  to: 

• Business  requirements,  including: 

o Business  and  project  objectives  for  traceability; 
o Business  rules  for  the  performing  organization;  and 
o Guiding  principles  of  the  organization. 
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• Stakeholder  requirements,  including: 

o Impacts  to  other  organizational  areas; 

o Impacts  to  other  entities  inside  or  outside  the  performing  organization;  and 
o Stakeholder  communication  and  reporting  requirements. 

• Solution  requirements,  including: 

o Functional  and  nonfunctional  requirements; 
o Technology  and  standard  compliance  requirements; 
o Support  and  training  requirements; 
o Quality  requirements;  and 

o Reporting  requirements,  etc.  (solution  requirements  can  be  documented  textually,  in  models, 
or  both). 

• Project  requirements,  such  as: 

o Levels  of  service,  performance,  safety,  compliance,  etc.;  and 
o Acceptance  criteria. 

• Transition  requirements. 

• Requirements  assumptions,  dependencies,  and  constraints. 

5.2.3.2  Requirements  Traceability  Matrix 

The  requirements  traceability  matrix  is  a grid  that  links  product  requirements  from  their  origin  to  the 
deliverables  that  satisfy  them.  The  implementation  of  a requirements  traceability  matrix  helps  ensure  that  each 
requirement  adds  business  value  by  linking  it  to  the  business  and  project  objectives.  It  provides  a means 
to  track  requirements  throughout  the  project  life  cycle,  helping  to  ensure  that  requirements  approved  in  the 
requirements  documentation  are  delivered  at  the  end  of  the  project.  Finally,  it  provides  a structure  for  managing 
changes  to  the  product  scope. 

Tracing  includes,  but  is  not  limited  to,  tracing  requirements  for  the  following: 
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• Business  needs,  opportunities,  goals,  and  objectives; 

• Project  objectives; 

• Project  scope/WBS  deliverables; 

• Product  design; 

• Product  development; 

• Test  strategy  and  test  scenarios;  and 

• High-level  requirements  to  more  detailed  requirements. 

Attributes  associated  with  each  requirement  can  be  recorded  in  the  requirements  traceability  matrix.  These 
attributes  help  to  define  key  information  about  the  requirement.  Typical  attributes  used  in  the  requirements 
traceability  matrix  may  include:  a unique  identifier,  a textual  description  of  the  requirement,  the  rationale 
for  inclusion,  owner,  source,  priority,  version,  current  status  (such  as  active,  cancelled,  deferred,  added, 
approved,  assigned,  completed),  and  status  date.  Additional  attributes  to  ensure  that  the  requirement  has  met 
stakeholders’  satisfaction  may  include  stability,  complexity,  and  acceptance  criteria.  Figure  5-6  provides  an 
example  of  a requirements  traceability  matrix  with  its  associated  attributes. 


Requirements  Traceability  Matrix 
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Figure  5-6.  Example  of  a Requirements  Traceability  Matrix 
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5.3  Define  Scope 

Define  Scope  is  the  process  of  developing  a detailed  description  of  the  project  and  product.  The  key  benefit  of 
this  process  is  that  it  describes  the  project,  service,  or  result  boundaries  by  defining  which  of  the  requirements 
collected  will  be  included  in  and  excluded  from  the  project  scope.  The  inputs,  tools  and  techniques,  and  outputs  of 
this  process  are  depicted  in  Figure  5-7.  Figure  5-8  depicts  the  data  flow  diagram  of  the  process. 
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Figure  5-7.  Define  Scope:  Inputs,  Tools  & Techniques,  and  Outputs 
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Since  all  of  the  requirements  identified  in  Collect  Requirements  may  not  be  included  in  the  project,  the  Define 
Scope  process  selects  the  final  project  requirements  from  the  requirements  documentation  delivered  during  the 
Collect  Requirements  process.  It  then  develops  a detailed  description  of  the  project  and  product,  service,  or  result. 

The  preparation  of  a detailed  project  scope  statement  is  critical  to  project  success  and  builds  upon  the  major 
deliverables,  assumptions,  and  constraints  that  are  documented  during  project  initiation.  During  project  planning, 
the  project  scope  is  defined  and  described  with  greater  specificity  as  more  information  about  the  project  is  known. 
Existing  risks,  assumptions,  and  constraints  are  analyzed  for  completeness  and  added  or  updated  as  necessary. 
The  Define  Scope  process  can  be  highly  iterative.  In  iterative  life  cycle  projects,  a high-level  vision  will  be  developed 
for  the  overall  project,  but  the  detailed  scope  is  determined  one  iteration  at  a time  and  the  detailed  planning  for  the 
next  iteration  is  carried  out  as  work  progresses  on  the  current  project  scope  and  deliverables. 

5.3.1  Define  Scope:  Inputs 

5.3.1 .1  Scope  Management  Plan 

Described  in  Section  5.1 .3.1  .The  scope  management  plan  is  a component  of  the  project  management  plan 
that  establishes  the  activities  for  developing,  monitoring,  and  controlling  the  project  scope. 

5.3.1 .2  Project  Charter 

Described  in  Section  4.1 .3.1.  The  project  charter  provides  the  high-level  project  description  and  product 
characteristics.  It  also  contains  project  approval  requirements.  If  a project  charter  is  not  used  in  the  performing 
organization,  then  comparable  information  needs  to  be  acquired  or  developed,  and  used  as  a basis  for  the  detailed 
project  scope  statement.  Organizations  that  do  not  produce  a formal  project  charter  will  usually  perform  an  informal 
analysis  to  identify  the  content  necessary  for  further  scope  planning. 

5.3.1 .3  Requirements  Documentation 

Described  in  Section  5.2. 3.1 . This  documentation  will  be  used  to  select  the  requirements  that  will  be  included 
in  the  project. 
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5.3.1 .4  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  Organizational  process  assets  can  influence  how  scope  is  defined.  Examples  include, 
but  are  not  limited  to: 

• Policies,  procedures,  and  templates  for  a project  scope  statement; 

• Project  files  from  previous  projects;  and 

• Lessons  learned  from  previous  phases  or  projects. 

5.3.2  Define  Scope:  Tools  and  Techniques 

5.3.2.1  Expert  Judgment 

Expert  judgment  is  often  used  to  analyze  the  information  needed  to  develop  the  project  scope  statement.  Such 
judgment  and  expertise  is  applied  to  any  technical  detail.  Such  expertise  is  provided  by  any  group  or  individual  with 
specialized  knowledge  or  training,  and  is  available  from  many  sources,  including  but  not  limited  to: 

• Other  units  within  the  organization; 

• Consultants; 

• Stakeholders,  including  customers  or  sponsors; 

• Professional  and  technical  associations; 

• Industry  groups;  and 

• Subject  matter  experts. 

5.3.2.2  Product  Analysis 

For  projects  that  have  a product  as  a deliverable,  as  opposed  to  a service  or  result,  product  analysis  can  be  an 
effective  tool.  Each  application  area  has  one  or  more  generally  accepted  methods  for  translating  high-level  product 
descriptions  into  tangible  deliverables.  Product  analysis  includes  techniques  such  as  product  breakdown,  systems 
analysis,  requirements  analysis,  systems  engineering,  value  engineering,  and  value  analysis. 


1 22  ©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  ( PMBOK ® Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


5 - PROJECT  SCOPE  MANAGEMENT 


5.3.2.3  Alternatives  Generation 

Alternatives  generation  is  a technique  used  to  develop  as  many  potential  options  as  possible  in  order  to  identify 
different  approaches  to  execute  and  perform  the  work  of  the  project.  A variety  of  general  management  techniques 
can  be  used,  such  as  brainstorming,  lateral  thinking,  analysis  of  alternatives,  etc. 

5.3.2.4  Facilitated  Workshops 

Described  in  Section  5.2. 2.3.  The  participation  of  key  players  with  a variety  of  expectations  and/or  fields  of 
expertise  in  these  intensive  working  sessions  helps  to  reach  a cross-functional  and  common  understanding  of  the 
project  objectives  and  its  limits. 

5.3.3  Define  Scope:  Outputs 
5.3.3.1  Project  Scope  Statement 

The  project  scope  statement  is  the  description  of  the  project  scope,  major  deliverables,  assumptions,  and 
constraints.  The  project  scope  statement  documents  the  entire  scope,  including  project  and  product  scope.  It 
describes,  in  detail,  the  project’s  deliverables  and  the  work  required  to  create  those  deliverables.  It  also  provides  a 
common  understanding  of  the  project  scope  among  project  stakeholders.  It  may  contain  explicit  scope  exclusions 
that  can  assist  in  managing  stakeholder  expectations.  It  enables  the  project  team  to  perform  more  detailed  planning, 
guides  the  project  team’s  work  during  execution,  and  provides  the  baseline  for  evaluating  whether  requests  for 
changes  or  additional  work  are  contained  within  or  outside  the  project’s  boundaries. 

The  degree  and  level  of  detail  to  which  the  project  scope  statement  defines  the  work  that  will  be  performed 
and  the  work  that  is  excluded  can  help  determine  how  well  the  project  management  team  can  control  the  overall 
project  scope.  The  detailed  project  scope  statement,  either  directly,  or  by  reference  to  other  documents,  includes 
the  following: 

• Product  scope  description.  Progressively  elaborates  the  characteristics  of  the  product,  service,  or  result 
described  in  the  project  charter  and  requirements  documentation. 

• Acceptance  criteria.  A set  of  conditions  that  is  required  to  be  met  before  deliverables  are  accepted. 

• Deliverable.  Any  unique  and  verifiable  product,  result,  or  capability  to  perform  a service  that  is  required 
to  be  produced  to  complete  a process,  phase,  or  project.  Deliverables  also  include  ancillary  results,  such 
as  project  management  reports  and  documentation.  These  deliverables  may  be  described  at  a summary 
level  or  in  great  detail. 
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• Project  exclusion.  Generally  identifies  what  is  excluded  from  the  project.  Explicitly  stating  what  is  out  of 
scope  for  the  project  helps  to  manage  stakeholders’  expectations. 

• Constraints.  A limiting  factor  that  affects  the  execution  of  a project  or  process.  Constraints  identified  with 
the  project  scope  statement  list  and  describe  the  specific  internal  or  external  restrictions  or  limitations 
associated  with  the  project  scope  that  affect  the  execution  of  the  project,  for  example,  a predefined 
budget  or  any  imposed  dates  or  schedule  milestones  that  are  issued  by  the  customer  or  performing 
organization.  When  a project  is  performed  under  an  agreement,  contractual  provisions  will  generally  be 
constraints.  Information  on  constraints  may  be  listed  in  the  project  scope  statement  or  in  a separate  log. 

• Assumptions.  A factor  in  the  planning  process  that  is  considered  to  be  true,  real,  or  certain,  without 
proof  or  demonstration.  Also  describes  the  potential  impact  of  those  factors  if  they  prove  to  be  false. 
Project  teams  frequently  identify,  document,  and  validate  assumptions  as  part  of  their  planning  process. 
Information  on  assumptions  may  be  listed  in  the  project  scope  statement  or  in  a separate  log. 

Although  the  project  charter  and  the  project  scope  statement  are  sometimes  perceived  as  containing  a certain 
degree  of  redundancy,  they  are  different  in  the  level  of  detail  contained  in  each.  The  project  charter  contains  high- 
level  information,  while  the  project  scope  statement  contains  a detailed  description  of  the  scope  elements.  These 
elements  are  progressively  elaborated  throughout  the  project.  Table  5-1  describes  some  of  the  key  elements  for 
each  document. 


Table  5-1 . Elements  of  the  Project  Charter  and  Project  Scope  Statement 


Project  Charter 

Project  purpose  or  justification 

Measurable  project  objectives 
and  related  success  criteria 

High-level  requirements 

High-level  project  description 

High-level  risks 

Summary  milestone  schedule 

Summary  budget 

Stakeholder  list 

Project  approval  requirements 
(what  constitutes  success,  who 
decides  it,  who  signs  off) 

Assigned  project  manager, 
responsibility,  and  authority 
level 

Name  and  authority  of  the 
sponsor  or  other  person(s) 
authorizing  the  project  charter 


Project  Scope  Statement 

Project  scope  description 
(progressively  elaborated) 

Acceptance  criteria 

Project  deliverables 

Project  exclusions 

Project  constraints 

Project  assumptions 
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5.3.3.2  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Stakeholder  register, 

• Requirements  documentation,  and 

• Requirements  traceability  matrix. 

5 

5.4  Create  WBS 

Create  WBS  is  the  process  of  subdividing  project  deliverables  and  project  work  into  smaller,  more  manageable 
components.  The  key  benefit  of  this  process  is  that  it  provides  a structured  vision  of  what  has  to  be  delivered.  The 
inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  5-9.  Figure  5-10  depicts  the  data 
flow  diagram  of  the  process. 


Inputs 
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Figure  5-9.  Create  WBS:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  5-10.  Create  WBS  Data  Flow  Diagram 


The  WBS  is  a hierarchical  decomposition  of  the  total  scope  of  work  to  be  carried  out  by  the  project  team  to 
accomplish  the  project  objectives  and  create  the  required  deliverables.  The  WBS  organizes  and  defines  the  total 
scope  of  the  project,  and  represents  the  work  specified  in  the  current  approved  project  scope  statement. 


The  planned  work  is  contained  within  the  lowest  level  of  WBS  components,  which  are  called  work  packages. 
A work  package  can  be  used  to  group  the  activities  where  work  is  scheduled  and  estimated,  monitored,  and 
controlled.  In  the  context  of  the  WBS,  work  refers  to  work  products  or  deliverables  that  are  the  result  of  activity  and 
not  to  the  activity  itself. 
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5.4.1  Create  WBS:  Inputs 

5.4.1 .1  Scope  Management  Plan 

Described  in  Section  5.1 .3.1 . The  scope  management  plan  specifies  how  to  create  the  WBS  from  the  detailed 
project  scope  statement  and  how  the  WBS  will  be  maintained  and  approved. 

5.4.1 .2  Project  Scope  Statement 

Described  in  Section  5.3. 3.1 . The  project  scope  statement  describes  the  work  that  will  be  performed  and  the 
work  that  is  excluded.  It  also  lists  and  describes  the  specific  internal  or  external  restrictions  or  limitations  that  may 
affect  the  execution  of  the  project. 

5.4.1 .3  Requirements  Documentation 

Described  in  Section  5.2. 3.1 . Detailed  requirements  documentation  is  essential  for  understanding  what  needs 
to  be  produced  as  the  result  of  the  project  and  what  needs  to  be  done  to  deliver  the  project  and  its  final  products. 

5.4.1 .4  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  Industry-specific  WBS  standards,  relevant  to  the  nature  of  the  project,  may  serve 
as  external  reference  sources  for  creation  of  the  WBS.  For  example,  engineering  projects  may  reference  ISO/IEC 
1 5288  on  Systems  Engineering  - System  Life  Cycle  Processes  [6],  to  create  a WBS  for  a new  project. 

5.4.1 .5  Organizational  Process  Assets 

Described  in  Section  2.1.4.  The  organizational  process  assets  that  can  influence  the  Create  WBS  process 
include,  but  are  not  limited  to: 

• Policies,  procedures,  and  templates  for  the  WBS; 

• Project  files  from  previous  projects;  and 

• Lessons  learned  from  previous  projects. 
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5.4.2  Create  WBS:  Tools  and  Techniques 

5.4.2.1  Decomposition 

Decomposition  is  a technique  used  for  dividing  and  subdividing  the  project  scope  and  project  deliverables  into 
smaller,  more  manageable  parts.  The  work  package  is  the  work  defined  at  the  lowest  level  of  the  WBS  for  which 
cost  and  duration  can  be  estimated  and  managed.  The  level  of  decomposition  is  often  guided  by  the  degree  of 
control  needed  to  effectively  manage  the  project.  The  level  of  detail  for  work  packages  will  vary  with  the  size 
and  complexity  of  the  project.  Decomposition  of  the  total  project  work  into  work  packages  generally  involves  the 
following  activities: 

• Identifying  and  analyzing  the  deliverables  and  related  work; 

• Structuring  and  organizing  the  WBS; 

• Decomposing  the  upper  WBS  levels  into  lower-level  detailed  components; 

• Developing  and  assigning  identification  codes  to  the  WBS  components;  and 

• Verifying  that  the  degree  of  decomposition  of  the  deliverables  is  appropriate. 

A portion  of  a WBS  with  some  branches  of  the  WBS  decomposed  down  through  the  work  package  level  is  shown 
in  Figure  5-11. 

5.4.2.2  Expert  Judgment 

Expert  judgment  is  often  used  to  analyze  the  information  needed  to  decompose  the  project  deliverables  down 
into  smaller  component  parts  in  order  to  create  an  effective  WBS.  Such  judgment  and  expertise  is  applied  to 
technical  details  of  the  project’s  scope  and  used  to  reconcile  differences  in  opinion  on  how  to  best  break  down 
the  overall  scope  of  the  project.  This  level  of  expertise  is  provided  by  any  group  or  individual  with  relevant  training, 
knowledge,  or  experience  with  similar  projects  or  business  areas.  Expert  judgment  can  also  come  in  the  form 
of  predefined  templates  that  provide  guidance  on  how  to  effectively  break  down  common  deliverables.  Such 
templates  may  be  industry  or  discipline  specific  or  may  come  from  experience  gained  in  similar  projects.  The 
project  manager,  in  collaboration  with  the  project  team,  then  determines  the  final  decomposition  of  the  project 
scope  into  the  discrete  work  packages  that  will  be  used  to  effectively  manage  the  work  of  the  project. 
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The  WBS  is  illustrative  only.  It  is  not  intended  to  represent  the  full  project  scope  of  any  specific  project, 
nor  to  imply  that  this  is  the  only  way  to  organize  a WBS  on  this  type  of  project. 


Figure  5-11.  Sample  WBS  Decomposed  Down  Through  Work  Packages 

A WBS  structure  may  be  created  through  various  approaches.  Some  of  the  popular  methods  include  the  top- 
down  approach,  the  use  of  organization-specific  guidelines,  and  the  use  of  WBS  templates.  A bottom-up  approach 
can  be  used  during  the  integration  of  subcomponents.  The  WBS  structure  can  be  represented  in  a number  of  forms, 
such  as: 

• Using  phases  of  the  project  life  cycle  as  the  second  level  of  decomposition,  with  the  product  and  project 
deliverables  inserted  at  the  third  level,  as  shown  in  Figure  5-12; 

• Using  major  deliverables  as  the  second  level  of  decomposition,  as  shown  in  Figure  5-1 3;  and 

• Incorporating  subcomponents  which  may  be  developed  by  organizations  outside  the  project  team,  such 
as  contracted  work.  The  seller  then  develops  the  supporting  contract  WBS  as  part  of  the  contracted  work. 
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The  WBS  is  illustrative  only.  It  is  not  intended  to  represent  the  full  project  scope  of  any  specific  project, 
nor  to  imply  that  this  is  the  only  way  to  organize  a WBS  on  this  type  of  project. 


Figure  5-12.  Sample  WBS  Organized  by  Phase 
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The  WBS  is  illustrative  only.  It  is  not  intended  to  represent  the  full  project  scope  of  any  specific  project, 
nor  to  imply  that  this  is  the  only  way  to  organize  a WBS  on  this  type  of  project. 


Figure  5-13.  Sample  WBS  with  Major  Deliverables 
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Decomposition  of  the  upper-level  WBS  components  requires  subdividing  the  work  for  each  of  the  deliverables 
or  subcomponents  into  its  most  fundamental  elements,  where  the  WBS  components  represent  verifiable  products, 
services,  or  results.  The  WBS  may  be  structured  as  an  outline,  an  organizational  chart,  or  other  method  that  identifies 
a hierarchical  breakdown.  Verifying  the  correctness  of  the  decomposition  requires  determining  that  the  lower-level 
WBS  components  are  those  that  are  necessary  and  sufficient  for  completion  of  the  corresponding  higher-level 
deliverables.  Different  deliverables  can  have  different  levels  of  decomposition.  To  arrive  at  a work  package,  the 
work  for  some  deliverables  needs  to  be  decomposed  only  to  the  next  level,  while  others  need  additional  levels  of 
decomposition.  As  the  work  is  decomposed  to  greater  levels  of  detail,  the  ability  to  plan,  manage,  and  control  the 
work  is  enhanced.  However,  excessive  decomposition  can  lead  to  nonproductive  management  effort,  inefficient 
use  of  resources,  decreased  efficiency  in  performing  the  work,  and  difficulty  aggregating  data  over  different  levels 
of  the  WBS. 

Decomposition  may  not  be  possible  for  a deliverable  or  subcomponent  that  will  be  accomplished  far  into  the 
future.  The  project  management  team  usually  waits  until  the  deliverable  or  subcomponent  is  agreed  on,  so  the 
details  of  the  WBS  can  be  developed.  This  technique  is  sometimes  referred  to  as  rolling  wave  planning. 

The  WBS  represents  all  product  and  project  work,  including  the  project  management  work.  The  total  of  the  work 
at  the  lowest  levels  should  roll  up  to  the  higher  levels  so  that  nothing  is  left  out  and  no  extra  work  is  performed. 
This  is  sometimes  called  the  100  percent  rule. 

For  specific  information  regarding  the  WBS,  refer  to  the  Practice  Standard  for  Work  Breakdown  Structures  - 
Second  Edition  [7],  This  standard  contains  industry-specific  examples  of  WBS  templates  that  can  be  tailored  to 
specific  projects  in  a particular  application  area. 

5.4.3  Create  WBS:  Outputs 
5.4.3.1  Scope  Baseline 

The  scope  baseline  is  the  approved  version  of  a scope  statement,  work  breakdown  structure  (WBS),  and  its 
associated  WBS  dictionary,  that  can  be  changed  only  through  formal  change  control  procedures  and  is  used  as  a 
basis  for  comparison.  It  is  a component  of  the  project  management  plan.  Components  of  the  scope  baseline  include: 

• Project  scope  statement.  The  project  scope  statement  includes  the  description  of  the  project  scope, 
major  deliverables,  assumptions,  and  constraints. 
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• WBS.  The  WBS  is  a hierarchical  decomposition  of  the  total  scope  of  work  to  be  carried  out  by  the  project 
team  to  accomplish  the  project  objectives  and  create  the  required  deliverables.  Each  descending  level 
of  the  WBS  represents  an  increasingly  detailed  definition  of  the  project  work.  The  WBS  is  finalized  by 
assigning  each  work  package  to  a control  account  and  establishing  a unique  identifier  for  that  work 
package  from  a code  of  accounts.  These  identifiers  provide  a structure  for  hierarchical  summation 
of  costs,  schedule,  and  resource  information.  A control  account  is  a management  control  point 
where  scope,  budget,  actual  cost,  and  schedule  are  integrated  and  compared  to  the  earned  value  for 
performance  measurement.  Control  accounts  are  placed  at  selected  management  points  in  the  WBS. 
Each  control  account  may  include  one  or  more  work  packages,  but  each  of  the  work  packages  should 
be  associated  with  only  one  control  account.  A control  account  may  include  one  or  more  planning 
packages.  A planning  package  is  a work  breakdown  structure  component  below  the  control  account 
with  known  work  content  but  without  detailed  schedule  activities. 

• WBS  dictionary.  The  WBS  dictionary  is  a document  that  provides  detailed  deliverable,  activity,  and 
scheduling  information  about  each  component  in  the  WBS.  The  WBS  dictionary  is  a document  that 
supports  the  WBS.  Information  in  the  WBS  dictionary  may  include,  but  is  not  limited  to: 

o Code  of  account  identifier, 
o Description  of  work, 
o Assumptions  and  constraints, 
o Responsible  organization, 
o Schedule  milestones, 
o Associated  schedule  activities, 
o Resources  required, 
o Cost  estimates, 
o Quality  requirements, 
o Acceptance  criteria, 
o Technical  references,  and 
o Agreement  information. 

5.4.3.2  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to,  requirements  documentation,  which  may 
need  to  be  updated  to  include  approved  changes.  If  approved  change  requests  result  from  the  Create  WBS  process, 
then  the  requirements  documentation  may  need  to  be  updated  to  include  approved  changes. 
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5.5  Validate  Scope 

Validate  Scope  is  the  process  of  formalizing  acceptance  of  the  completed  project  deliverables.  The  key  benefit 
of  this  process  is  that  it  brings  objectivity  to  the  acceptance  process  and  increases  the  chance  of  final  product, 
service,  or  result  acceptance  by  validating  each  deliverable.  The  inputs,  tools  and  techniques,  and  outputs  of  this 
process  are  depicted  in  Figure  5-1 4.  Figure  5-1 5 depicts  the  data  flow  diagram  of  the  process. 
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Figure  5-14.  Validate  Scope:  Inputs,  Tools  & Techniques,  and  Outputs 
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The  verified  deliverables  obtained  from  the  Control  Quality  process  are  reviewed  with  the  customer  or  sponsor 
to  ensure  that  they  are  completed  satisfactorily  and  have  received  formal  acceptance  of  the  deliverables  by  the 
customer  or  sponsor.  In  this  process,  the  outputs  obtained  as  a result  of  the  Planning  processes  in  the  Project  Scope 
Management  Knowledge  Area,  such  as  the  requirements  documentation  or  the  scope  baseline,  as  well  as  the  work 
performance  data  obtained  from  the  Execution  processes  in  other  Knowledge  Areas,  are  the  basis  for  performing 
the  validation  and  for  final  acceptance. 

The  Validate  Scope  process  differs  from  the  Control  Quality  process  in  that  the  former  is  primarily  concerned 
with  acceptance  of  the  deliverables,  while  quality  control  is  primarily  concerned  with  correctness  of  the  deliverables 
and  meeting  the  quality  requirements  specified  for  the  deliverables.  Control  Quality  is  generally  performed  before 
Validate  Scope,  although  the  two  processes  may  be  performed  in  parallel. 

5.5.1  Validate  Scope:  Inputs 

5.5.1 .1  Project  Management  Plan 

Described  in  Section  4.2. 3.1 . The  project  management  plan  contains  the  scope  management  plan  and  the 
scope  baseline.  As  described  in  Section  5.1 .3.1 , the  scope  management  plan  specifies  how  formal  acceptance  of 
the  completed  project  deliverables  will  be  obtained.  The  scope  baseline  (Section  5. 4.3.1)  includes  the  approved 
version  of  a scope  statement,  work  breakdown  structure  (WBS),  and  its  associated  WBS  dictionary,  that  can  be 
changed  only  through  formal  change  control  procedures  and  is  used  as  a basis  for  comparison. 

5.5.1 .2  Requirements  Documentation 

Described  in  Section  5. 2.3.1.  The  requirements  documentation  lists  all  the  project,  product,  and  other  types  of 
requirements  for  the  project  and  product,  along  with  their  acceptance  criteria. 

5.5.1 .3  Requirements  Traceability  Matrix 

Described  in  Section  5.2. 3.2.  The  requirements  traceability  matrix  links  requirements  to  their  origin  and  tracks 
them  throughout  the  project  life  cycle. 
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5.5.1 .4  Verified  Deliverables 

Described  in  Section  8.3. 3.3.  Verified  deliverables  are  project  deliverables  that  are  completed  and  checked  for 
correctness  through  the  Control  Quality  process. 

5.5.1 .5  Work  Performance  Data 

Described  in  Section  4.3. 3.2.  Work  performance  data  can  include  the  degree  of  compliance  with  requirements, 
number  of  nonconformities,  severity  of  the  nonconformities,  or  the  number  of  validation  cycles  performed  in  a 
period  of  time. 

5.5.2  Validate  Scope:  Tools  and  Techniques 

5.5.2.1  Inspection 

Inspection  includes  activities  such  as  measuring,  examining,  and  validating  to  determine  whether  work  and 
deliverables  meet  requirements  and  product  acceptance  criteria.  Inspections  are  sometimes  called  reviews, 
product  reviews,  audits,  and  walkthroughs.  In  some  application  areas,  these  different  terms  have  unique  and 
specific  meanings. 

5.5.2.2  Group  Decision-Making  Techniques 

Described  in  Section  5.2. 2.5.  These  techniques  are  used  to  reach  a conclusion  when  the  validation  is  performed 
by  the  project  team  and  other  stakeholders. 

5.5.3  Validate  Scope:  Outputs 
5.5.3.1  Accepted  Deliverables 

Deliverables  that  meet  the  acceptance  criteria  are  formally  signed  off  and  approved  by  the  customer  or  sponsor. 
Formal  documentation  received  from  the  customer  or  sponsor  acknowledging  formal  stakeholder  acceptance  of 
the  project’s  deliverables  is  forwarded  to  the  Close  Project  or  Phase  process  (Section  4.6). 
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5.5.3.2  Change  Requests 

The  completed  deliverables  that  have  not  been  formally  accepted  are  documented,  along  with  the  reasons 
for  nonacceptance  of  those  deliverables.  Those  deliverables  may  require  a change  request  for  defect  repair.  The 
change  requests  are  processed  for  review  and  disposition  through  the  Perform  Integrated  Change  Control  process 
(Section  4.5). 

5.5.3.3  Work  Performance  Information 

Work  performance  information  includes  information  about  project  progress,  such  as  which  deliverables 
have  started,  their  progress,  which  deliverables  have  finished,  or  which  have  been  accepted.  This  information  is 
documented  as  described  in  Section  10.3.3.1  and  communicated  to  stakeholders. 

5.5.3.4  Project  Documents  Updates 

Project  documents  that  may  be  updated  as  a result  of  the  Validate  Scope  process  include  any  documents  that 
define  the  product  or  report  status  on  product  completion.  Verified  project  documents  may  require  approvals  from 
the  customer  or  sponsor  in  the  form  of  signatures  or  signoffs. 


5.6  Control  Scope 

Control  Scope  is  the  process  of  monitoring  the  status  of  the  project  and  product  scope  and  managing  changes  to 
the  scope  baseline.  The  key  benefit  of  this  process  is  that  it  allows  the  scope  baseline  to  be  maintained  throughout 
the  project.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  5-16.  Figure  5-17 
depicts  the  data  flow  diagram  of  the  process. 
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Figure  5-16.  Control  Scope:  Inputs,  Tools  & Techniques,  and  Outputs 


136  ©2013  Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  ( PMBOK ® Guide) -Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


5 - PROJECT  SCOPE  MANAGEMENT 


Project  Scope  Management 


- 

Enterprise/ 

Organization 

4.2 

Develop  Project 
Management 
Plan 

4.3 

Direct  and 
Manage  Project 
Work 


5.2 


Collect 

Requirements 


• Requirements 
documentation 

• Requirements 
traceability  matrix 


• Organizational 
process  assets 


• Project 

management  plan 

• Work  performance 
data 


► 

► 


► 


▼ 

5.6 

Control 

Scope 


• Project  documents 
updates 

► 

• Project  management 
plan  updates 

• Work  performance 
information 

► 


• Change 
requests 


* Organizational  process 
assets  updates 


4.2 

Develop  Project 
Management 
Plan 

4.4 

Monitor  and 
Control  Project 
Work 

4.5 

Perform 
Integrated 
Change  Control 

Enterprise/ 

Organization 


Figure  5-17.  Control  Scope  Data  Flow  Diagram 


Controlling  the  project  scope  ensures  all  requested  changes  and  recommended  corrective  or  preventive  actions 
are  processed  through  the  Perform  Integrated  Change  Control  process  (see  Section  4.5).  Control  Scope  is  also  used 
to  manage  the  actual  changes  when  they  occur  and  is  integrated  with  the  other  control  processes.  The  uncontrolled 
expansion  to  product  or  project  scope  without  adjustments  to  time,  cost,  and  resources  is  referred  to  as  scope 
creep.  Change  is  inevitable;  therefore  some  type  of  change  control  process  is  mandatory  for  every  project. 
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5.6.1  Control  Scope:  Inputs 

5.6.1 .1  Project  Management  Plan 

Described  in  Section  4. 2.3.1.  The  following  information  from  the  project  management  plan  is  used  to  control 
scope: 

• Scope  baseline.  The  scope  baseline  is  compared  to  actual  results  to  determine  if  a change,  corrective 
action,  or  preventive  action  is  necessary. 

• Scope  management  plan.  Sections  from  the  scope  management  plan  describe  how  the  project  scope 
will  be  monitored  and  controlled. 

• Change  management  plan.  The  change  management  plan  defines  the  process  for  managing  change 
on  the  project. 

• Configuration  management  plan.  The  configuration  management  plan  defines  those  items  that  are 
configurable,  those  items  that  require  formal  change  control,  and  the  process  for  controlling  changes  to 
such  items. 

• Requirements  management  plan.  This  plan  is  a component  of  the  project  management  plan  and 
describes  how  the  project  requirements  will  be  analyzed,  documented,  and  managed. 

5.6.1 .2  Requirements  Documentation 

Described  in  Section  5. 2.3.1.  Requirements  should  be  unambiguous  (measurable  and  testable),  traceable, 
complete,  consistent,  and  acceptable  to  key  stakeholders.  Well-documented  requirements  make  it  easier  to  detect 
any  deviation  in  the  scope  agreed  for  the  project  or  product. 

5.6.1 .3  Requirements  Traceability  Matrix 

Described  in  Section  5. 2.3. 2.  The  requirements  traceability  matrix  helps  to  detect  the  impact  of  any  change  or 
deviation  from  the  scope  baseline  on  the  project  objectives. 
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5.6.1 .4  Work  Performance  Data 

Described  in  Section  4. 3.3. 2.  Work  performance  data  can  include  the  number  of  change  requests  received,  the 
number  of  requests  accepted  or  the  number  of  deliverables  completed,  etc. 

5.6.1 .5  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  can  influence  the  Control  Scope  process 
include,  but  are  not  limited  to: 

• Existing  formal  and  informal  scope,  control-related  policies,  procedures,  guidelines;  and 

• Monitoring  and  reporting  methods  and  templates  to  be  used. 

5.6.2  Control  Scope:  Tools  and  Techniques 

5.6.2.1  Variance  Analysis 

Variance  analysis  is  a technique  for  determining  the  cause  and  degree  of  difference  between  the  baseline  and 
actual  performance.  Project  performance  measurements  are  used  to  assess  the  magnitude  of  variation  from  the 
original  scope  baseline.  Important  aspects  of  project  scope  control  include  determining  the  cause  and  degree  of 
variance  relative  to  the  scope  baseline  (Section  5. 4.3.1)  and  deciding  whether  corrective  or  preventive  action  is 
required. 

5.6.3  Control  Scope:  Outputs 

5.6.3.1  Work  Performance  Information 

Work  performance  information  produced  includes  correlated  and  contextualized  information  on  how  the  project 
scope  is  performing  compared  to  the  scope  baseline.  It  can  include  the  categories  of  the  changes  received,  the 
identified  scope  variances  and  their  causes,  how  they  impact  schedule  or  cost,  and  the  forecast  of  the  future  scope 
performance.  This  information  provides  a foundation  for  making  scope  decisions. 
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5.6.3.2  Change  Requests 

Analysis  of  scope  performance  can  result  in  a change  request  to  the  scope  baseline  or  other  components 
of  the  project  management  plan.  Change  requests  can  include  preventive  or  corrective  actions,  defect  repairs, 
or  enhancement  requests.  Change  requests  are  processed  for  review  and  disposition  according  to  the  Perform 
Integrated  Change  Control  process  (Section  4.5). 

5.6.3.3  Project  Management  Plan  Updates 

Project  management  plan  updates  may  include,  but  are  not  limited  to: 

• Scope  Baseline  Updates.  If  the  approved  change  requests  have  an  effect  on  the  project  scope,  then 
the  scope  statement,  the  WBS,  and  the  WBS  dictionary  are  revised  and  reissued  to  reflect  the  approved 
changes  through  Perform  Integrated  Change  Control  process. 

• Other  Baseline  Updates.  If  the  approved  change  requests  have  an  effect  on  the  project  besides  the 
project  scope,  then  the  corresponding  cost  baseline  and  schedule  baselines  are  revised  and  reissued  to 
reflect  the  approved  changes. 

5.6.3.4  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Requirements  documentation,  and 

• Requirements  traceability  matrix. 

5.6.3.5  Organizational  Process  Assets  Updates 

Organizational  process  assets  that  may  be  updated  include,  but  are  not  limited  to: 

• Causes  of  variances, 

• Corrective  action  chosen  and  the  reasons,  and 

• Other  types  of  lessons  learned  from  project  scope  control. 
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PROJECT  TIME  MANAGEMENT 


Project  Time  Management  includes  the  processes  required  to  manage  the  timely  completion  of  the  project. 

Figure  6-1  provides  an  overview  of  the  Project  Time  Management  processes,  which  are  as  follows: 

6.1  Plan  Schedule  Management — The  process  of  establishing  the  policies,  procedures,  and  documentation 
for  planning,  developing,  managing,  executing,  and  controlling  the  project  schedule. 

6.2  Define  Activities — The  process  of  identifying  and  documenting  the  specific  actions  to  be  performed 
to  produce  the  project  deliverables. 

6.3  Sequence  Activities — The  process  of  identifying  and  documenting  relationships  among  the  project 
activities. 

6.4  Estimate  Activity  Resources — The  process  of  estimating  the  type  and  quantities  of  material,  human 
resources,  equipment,  or  supplies  required  to  perform  each  activity. 

6.5  Estimate  Activity  Durations — The  process  of  estimating  the  number  of  work  periods  needed  to 
complete  individual  activities  with  estimated  resources. 

6.6  Develop  Schedule — The  process  of  analyzing  activity  sequences,  durations,  resource  requirements, 
and  schedule  constraints  to  create  the  project  schedule  model. 

6.7  Control  Schedule — The  process  of  monitoring  the  status  of  project  activities  to  update  project 
progress  and  manage  changes  to  the  schedule  baseline  to  achieve  the  plan. 
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These  processes  interact  with  each  other  and  with  processes  in  other  Knowledge  Areas  as  described  in  detail 
in  Section  3 and  Annex  A1. 

Distinguishing  the  project  schedule  presentation  (schedule)  from  the  schedule  data  (Section  6. 6.3. 3)  and 
calculations  that  produce  the  project  schedule  (Section  6.6. 3.2)  is  practiced  by  referring  to  the  scheduling  tool 
populated  with  project  data  as  the  schedule  model.  A schedule  model  is  a representation  of  the  plan  for  executing 
the  project’s  activities  including  durations,  dependencies,  and  other  planning  information,  used  to  produce  project 
schedules  along  with  other  scheduling  artifacts.  For  specific  information  regarding  the  schedule  model,  refer  to  the 
Practice  Standard  for  Scheduling.  [8] 

On  some  projects,  especially  those  of  smaller  scope,  defining  activities,  sequencing  activities,  estimating 
activity  resources,  estimating  activity  durations,  and  developing  the  schedule  model  are  so  tightly  linked  that  they 
are  viewed  as  a single  process  that  can  be  performed  by  a person  over  a relatively  short  period  of  time.  These 
processes  are  presented  here  as  distinct  elements  because  the  tools  and  techniques  for  each  process  are  different. 

The  Project  Time  Management  processes  and  their  associated  tools  and  techniques  are  documented  in  the 
schedule  management  plan.  The  schedule  management  plan  is  a subsidiary  plan  of,  and  integrated  with,  the  project 
management  plan  through  the  Develop  Project  Management  Plan  process  (Section  4.2),  The  schedule  management 
plan  identifies  a scheduling  method  and  scheduling  tool  (Figure  6-2),  and  sets  the  format  and  establishes  criteria 
for  developing  and  controlling  the  project  schedule.  The  selected  scheduling  method  defines  the  framework  and 
algorithms  used  in  the  scheduling  tool  to  create  the  schedule  model.  Some  of  the  better  known  scheduling  methods 
include  critical  path  method  (CPM)  and  critical  chain  method  (CCM). 

Project  schedule  development  uses  the  outputs  from  the  processes  to  define  activities,  sequence  activities, 
estimate  activity  resources,  and  estimate  activity  durations  in  combination  with  the  scheduling  tool  to  produce 
the  schedule  model.  The  finalized  and  approved  schedule  is  the  baseline  that  will  be  used  in  the  Control  Schedule 
process  (Section  6.7).  As  the  project  activities  are  being  performed,  the  majority  of  effort  in  the  Project  Time 
Management  Knowledge  Area  will  occur  in  the  Control  Schedule  process  to  ensure  completion  of  project  work  in  a 
timely  manner.  Figure  6-2  provides  a scheduling  overview  that  shows  how  the  scheduling  method,  scheduling  tool, 
and  outputs  from  the  Project  Time  Management  processes  interact  to  create  a project  schedule. 
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Figure  6-1 . Project  Time  Management  Overview 
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Figure  6-2.  Scheduling  Overview 
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6.1  Plan  Schedule  Management 

Plan  Schedule  Management  is  the  process  of  establishing  the  policies,  procedures,  and  documentation  for 
planning,  developing,  managing,  executing,  and  controlling  the  project  schedule.  The  key  benefit  of  this  process  is 
that  it  provides  guidance  and  direction  on  how  the  project  schedule  will  be  managed  throughout  the  project.  The 
inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  6-3.  Figure  6-4  depicts  the  data 
flow  diagram  of  the  process. 
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Figure  6-3.  Plan  Schedule  Management:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  6-4.  Plan  Schedule  Management  Data  Flow  Diagram 
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The  schedule  management  plan  is  a component  of  the  project  management  plan.  The  schedule  management 
plan  may  be  formal  or  informal,  highly  detailed  or  broadly  framed,  based  upon  the  needs  of  the  project,  and 
includes  appropriate  control  thresholds.  The  schedule  management  plan  defines  how  schedule  contingencies  will 
be  reported  and  assessed.  The  schedule  management  plan  may  be  updated  to  reflect  a change  in  the  way  the 
schedule  is  managed.  The  schedule  management  plan  is  a major  input  into  the  Develop  Project  Management  Plan 
process,  as  referenced  in  Section  6.1 .3.1 . 

6.1.1  Plan  Schedule  Management:  Inputs 

6.1 .1 .1  Project  Management  Plan 

Described  in  Section  4. 2.3.1.  The  project  management  plan  contains  information  used  to  develop  the  schedule 
management  plan  which  includes,  but  is  not  limited  to: 

• Scope  baseline.  The  scope  baseline  includes  the  project  scope  statement  and  the  work  breakdown 
structure  (WBS)  details  used  for  defining  activities,  duration  estimation,  and  schedule  management;  and 

• Other  information.  Other  scheduling  related  cost,  risk,  and  communications  decisions  from  the  project 
management  plan  are  used  to  develop  the  schedule. 

6.1 .1 .2  Project  Charter 

Described  in  Section  4.1 .3.1 . The  project  charter  defines  the  summary  milestone  schedule  and  project  approval 
requirements  that  will  influence  the  management  of  the  project  schedule. 

6.1 .1 .3  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  The  enterprise  environmental  factors  that  influence  the  Plan  Schedule  Management 
process  include,  but  are  not  limited  to: 

• Organizational  culture  and  structure  can  all  influence  schedule  management; 

• Resource  availability  and  skills  that  may  influence  schedule  planning; 

• Project  management  software  provides  the  scheduling  tool  and  alternative  possibilities  for  managing  the 
schedule; 

• Published  commercial  information,  such  as  resource  productivity  information,  is  often  available  from 
commercial  databases  that  track;  and 

• Organizational  work  authorization  systems. 
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6.1 .1 .4  Organizational  Process  Assets 

Described  in  Section  2.1.4.  The  organizational  process  assets  that  influence  the  Plan  Schedule  Management 
process  include,  but  are  not  limited  to: 

• Monitoring  and  reporting  tools  to  be  used; 

• Historical  information; 

• Schedule  control  tools; 

• Existing  formal  and  informal  schedule  control  related  policies,  procedures,  and  guidelines; 

• Templates; 

• Project  closure  guidelines; 

• Change  control  procedures;  and 

• Risk  control  procedures  including  risk  categories,  probability  definition  and  impact,  and  probability  and 
impact  matrix. 

6.1.2  Plan  Schedule  Management:  Tools  and  Techniques 

6.1 .2.1  Expert  Judgment 

Expert  judgment,  guided  by  historical  information,  provides  valuable  insight  about  the  environment  and 
information  from  prior  similar  projects.  Expert  judgment  can  also  suggest  whether  to  combine  methods  and  how  to 
reconcile  differences  between  them. 

Judgment  based  upon  expertise  in  an  application  area,  Knowledge  Area,  discipline,  industry,  etc.,  as  appropriate 
for  the  activity  being  performed,  should  be  used  in  developing  the  schedule  management  plan. 

6.1 .2.2  Analytical  Techniques 

The  Plan  Schedule  Management  process  may  involve  choosing  strategic  options  to  estimate  and  schedule  the 
project  such  as:  scheduling  methodology,  scheduling  tools  and  techniques,  estimating  approaches,  formats,  and 
project  management  software.  The  schedule  management  plan  may  also  detail  ways  to  fast  track  or  crash  (Section 
6. 6.2. 7)  the  project  schedule  such  as  undertaking  work  in  parallel.  These  decisions,  like  other  schedule  decisions 
affecting  the  project,  may  affect  project  risks. 
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Organizational  policies  and  procedures  may  influence  which  scheduling  techniques  are  employed  in  these 
decisions.  Techniques  may  include,  but  are  not  limited  to,  rolling  wave  planning  (Section  6.2. 2.2),  leads  and  lags 
(Section  6.3. 2.3),  alternatives  analysis  (Section  6. 4.2. 2),  and  methods  for  reviewing  schedule  performance  (Section 
6. 7. 2.1). 

6.1 .2.3  Meetings 

Project  teams  may  hold  planning  meetings  to  develop  the  schedule  management  plan.  Participants  at  these 
meetings  may  include  the  project  manager,  the  project  sponsor,  selected  project  team  members,  selected 
stakeholders,  anyone  with  responsibility  for  schedule  planning  or  execution,  and  others  as  needed. 

6.1.3  Plan  Schedule  Management:  Outputs 
6.1 .3.1  Schedule  Management  Plan 

A component  of  the  project  management  plan  that  establishes  the  criteria  and  the  activities  for  developing, 
monitoring,  and  controlling  the  schedule. The  schedule  management  plan  may  be  formal  or  informal,  highly  detailed 
or  broadly  framed,  based  upon  the  needs  of  the  project,  and  includes  appropriate  control  thresholds. 

For  example,  the  schedule  management  plan  can  establish  the  following: 

• Project  schedule  model  development.  The  scheduling  methodology  and  the  scheduling  tool  to  be  used 
in  the  development  of  the  project  schedule  model  are  specified. 

• Level  of  accuracy.  The  acceptable  range  used  in  determining  realistic  activity  duration  estimates  is 
specified  and  may  include  an  amount  for  contingencies. 

• Units  of  measure.  Each  unit  used  in  measurements  (such  as  staff  hours,  staff  days,  or  weeks  for  time 
measures,  or  meters,  liters,  tons,  kilometers,  or  cubic  yards  for  quantity  measures)  is  defined  for  each  of 
the  resources. 

• Organizational  procedures  links.  The  WBS  (Section  5.4)  provides  the  framework  for  the  schedule 
management  plan,  allowing  for  consistency  with  the  estimates  and  resulting  schedules. 

• Project  schedule  model  maintenance.  The  process  used  to  update  the  status  and  record  progress  of 
the  project  in  the  schedule  model  during  the  execution  of  the  project  is  defined. 

• Control  thresholds.  Variance  thresholds  for  monitoring  schedule  performance  may  be  specified  to  indicate 
an  agreed-upon  amount  of  variation  to  be  allowed  before  some  action  needs  to  be  taken.  Thresholds  are 
typically  expressed  as  percentage  deviations  from  the  parameters  established  in  the  baseline  plan. 
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• Rules  of  performance  measurement.  Earned  value  management  (EVM)  rules  or  other  physical 
measurement  rules  of  performance  measurement  are  set.  For  example,  the  schedule  management  plan 
may  specify: 

o Rules  for  establishing  percent  complete, 

o Control  accounts  at  which  management  of  progress  and  schedule  will  be  measured, 

o Earned  value  measurement  techniques  (e.g.,  baselines,  fixed-formula,  percent  complete,  etc.) 
to  be  employed  (for  more  specific  information,  refer  to  the  Practice  Standard  for  Earned  Value 
Management}  [9], 

o Schedule  performance  measurements  such  as  schedule  variance  (SV)  and  schedule  performance 
index  (SPI)  used  to  assess  the  magnitude  of  variation  to  the  original  schedule  baseline. 

• Reporting  formats.  The  formats  and  frequency  for  the  various  schedule  reports  are  defined. 

• Process  descriptions.  Descriptions  of  each  of  the  schedule  management  processes  are  documented. 


6.2  Define  Activities 

Define  Activities  is  the  process  of  identifying  and  documenting  the  specific  actions  to  be  performed  to  produce 
the  project  deliverables.  The  key  benefit  of  this  process  is  to  break  down  work  packages  into  activities  that  provide 
a basis  for  estimating,  scheduling,  executing,  monitoring,  and  controlling  the  project  work.  The  inputs,  tools  and 
techniques,  and  outputs  of  this  process  are  depicted  in  Figure  6-5.  Figure  6-6  depicts  the  dataflow  diagram  of  the 
process. 
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Figure  6-5.  Define  Activities:  Inputs,  Tools  & Techniques,  and  Outputs 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK®  Guide)  - Fifth  Edition 


149 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


6 - PROJECT  TIME  MANAGEMENT 


Project  Time  Management 


Figure  6-6.  Define  Activities  Data  Flow  Diagram 

Implicit  in  this  process  are  defining  and  planning  the  schedule  activities  such  that  the  project  objectives  will 
be  met.  The  Create  WBS  process  identifies  the  deliverables  at  the  lowest  level  in  the  WBS — the  work  package. 
Work  packages  are  typically  decomposed  into  smaller  components  called  activities  that  represent  the  work  effort 
required  to  complete  the  work  package. 

6.2.1  Define  Activities:  Inputs 

6.2.1 .1  Schedule  Management  Plan 

Described  in  Section  6.1 .3.1 . A key  input  from  the  schedule  management  plan  is  the  prescribed  level  of  detail 
necessary  to  manage  the  work. 
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6.2.1 .2  Scope  Baseline 

Described  in  Section  5. 4.3.1.  The  project  WBS,  deliverables,  constraints,  and  assumptions  documented  in  the 
scope  baseline  are  considered  explicitly  while  defining  activities. 

6.2.1 .3  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  Enterprise  environmental  factors  that  influence  the  Define  Activities  process  include, 
but  are  not  limited  to: 

• Organizational  cultures  and  structure, 

• Published  commercial  information  from  commercial  databases,  and 

• Project  management  information  system  (PMIS). 

6.2.1 .4  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  can  influence  the  Define  Activities  process 
include,  but  are  not  limited  to: 

• Lessons  learned  knowledge  base  containing  historical  information  regarding  activity  lists  used  by  previous 
similar  projects, 

• Standardized  processes, 

• Templates  that  contain  a standard  activity  list  or  a portion  of  an  activity  list  from  a previous  project,  and 

• Existing  formal  and  informal  activity  planning-related  policies,  procedures,  and  guidelines,  such  as  the 
scheduling  methodology,  that  are  considered  in  developing  the  activity  definitions. 

6.2.2  Define  Activities:  Tools  and  Techniques 

6.2.2.1  Decomposition 

Decomposition  is  a technique  used  for  dividing  and  subdividing  the  project  scope  and  project  deliverables  into 
smaller,  more  manageable  parts.  Activities  represent  the  effort  needed  to  complete  a work  package.  The  Define 
Activities  process  defines  the  final  outputs  as  activities  rather  than  deliverables,  as  done  in  the  Create  WBS  process 
(Section  5.4). 
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The  activity  list,  WBS,  and  WBS  dictionary  can  be  developed  either  sequentially  or  concurrently,  with  the  WBS 
and  WBS  dictionary  as  the  basis  for  development  of  the  final  activity  list.  Each  work  package  within  the  WBS  is 
decomposed  into  the  activities  required  to  produce  the  work  package  deliverables.  Involving  team  members  in  the 
decomposition  can  lead  to  better  and  more  accurate  results. 

6.2.2.2  Rolling  Wave  Planning 

Rolling  wave  planning  is  an  iterative  planning  technique  in  which  the  work  to  be  accomplished  in  the  near  term 
is  planned  in  detail,  while  the  work  in  the  future  is  planned  at  a higher  level.  It  is  a form  of  progressive  elaboration. 
Therefore,  work  can  exist  at  various  levels  of  detail  depending  on  where  it  is  in  the  project  life  cycle.  During  early 
strategic  planning,  when  information  is  less  defined,  work  packages  may  be  decomposed  to  the  known  level  of 
detail.  As  more  is  known  about  the  upcoming  events  in  the  near  term,  work  packages  can  be  decomposed  into 
activities. 

6.2.2.3  Expert  Judgment 

Project  team  members  or  other  experts,  who  are  experienced  and  skilled  in  developing  detailed  project  scope 
statements,  the  WBS,  and  project  schedules,  can  provide  expertise  in  defining  activities. 

6.2.3  Define  Activities:  Outputs 

6.2.3.1  Activity  List 

The  activity  list  is  a comprehensive  list  that  includes  all  schedule  activities  required  on  the  project.  The  activity 
list  also  includes  the  activity  identifier  and  a scope  of  work  description  for  each  activity  in  sufficient  detail  to  ensure 
that  project  team  members  understand  what  work  is  required  to  be  completed.  Each  activity  should  have  a unique 
title  that  describes  its  place  in  the  schedule,  even  if  that  activity  title  is  displayed  outside  the  context  of  the  project 
schedule. 
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6.2.3.2  Activity  Attributes 

Activities,  distinct  from  milestones,  have  durations,  during  which  the  work  of  that  activity  is  performed, 
and  may  have  resources  and  costs  associated  with  that  work.  Activity  attributes  extend  the  description  of 
the  activity  by  identifying  the  multiple  components  associated  with  each  activity.  The  components  for  each 
activity  evolve  over  time.  During  the  initial  stages  of  the  project,  they  include  the  activity  identifier  (ID),  WBS  ID, 
and  activity  label  or  name,  and  when  completed,  may  include  activity  codes,  activity  description,  predecessor 
activities,  successor  activities,  logical  relationships,  leads  and  lags  (Section  6. 3. 2. 3),  resource  requirements, 
imposed  dates,  constraints,  and  assumptions.  Activity  attributes  can  be  used  to  identify  the  person  responsible 
for  executing  the  work,  geographic  area,  or  place  where  the  work  has  to  be  performed,  the  project  calendar 
the  activity  is  assigned  to,  and  activity  type  such  as  level  of  effort  (often  abbreviated  as  LOE),  discrete  effort, 
and  apportioned  effort.  Activity  attributes  are  used  for  schedule  development  and  for  selecting,  ordering,  and 
sorting  the  planned  schedule  activities  in  various  ways  within  reports.  The  number  of  attributes  varies  by 
application  area. 

6.2.3.3  Milestone  List 

A milestone  is  a significant  point  or  event  in  a project.  A milestone  list  is  a list  identifying  all  project  milestones 
and  indicates  whether  the  milestone  is  mandatory,  such  as  those  required  by  contract,  or  optional,  such  as  those 
based  upon  historical  information.  Milestones  are  similar  to  regular  schedule  activities,  with  the  same  structure  and 
attributes,  but  they  have  zero  duration  because  milestones  represent  a moment  in  time. 


6.3  Sequence  Activities 

Sequence  Activities  is  the  process  of  identifying  and  documenting  relationships  among  the  project  activities.  The 
key  benefit  of  this  process  is  that  it  defines  the  logical  sequence  of  work  to  obtain  the  greatest  efficiency  given  all 
project  constraints.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  6-7.  Figure 
6-8  depicts  the  data  flow  diagram  of  the  process. 
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Figure  6-7.  Sequence  Activities:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  6-8.  Sequence  Activities  Data  Flow  Diagram 


Every  activity  and  milestone  except  the  first  and  last  should  be  connected  to  at  least  one  predecessor  with  a 
finish-to-start  or  start-to-start  logical  relationship  and  at  least  one  successor  with  a finish-to-start  or  finish-to- 
finish  logical  relationship.  Logical  relationships  should  be  designed  to  create  a realistic  project  schedule.  It  may 
be  necessary  to  use  lead  or  lag  time  between  activities  to  support  a realistic  and  achievable  project  schedule. 
Sequencing  can  be  performed  by  using  project  management  software  or  by  using  manual  or  automated  techniques. 


6.3.1  Sequence  Activities:  Inputs 

6.3.1 .1  Schedule  Management  Plan 

Described  in  Section  6.1 .3.1 . The  schedule  management  plan  identifies  the  scheduling  method  and  tool  to  be 
used  for  the  project,  which  will  guide  how  the  activities  may  be  sequenced. 
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6.3.1 .2  Activity  List 

Described  in  Section  6. 2.3.1.  The  activity  list  contains  all  schedule  activities  required  on  the  project,  which 
are  to  be  sequenced.  Dependencies  and  other  constraints  for  these  activities  can  influence  the  sequencing  of  the 
activities. 

6.3.1 .3  Activity  Attributes 

Described  in  Section  6. 2.3. 2.  Activity  attributes  may  describe  a necessary  sequence  of  events  or  defined 
predecessor  or  successor  relationships. 

6.3.1 .4  Milestone  List 

Described  in  Section  6. 2.3. 3.  The  milestone  list  may  have  scheduled  dates  for  specific  milestones,  which  may 
influence  the  way  activities  are  sequenced. 

6.3.1 .5  Project  Scope  Statement 

Described  in  Section  5.3. 3.1  .The  project  scope  statement  contains  the  product  scope  description,  which  includes 
product  characteristics  that  may  affect  activity  sequencing,  such  as  the  physical  layout  of  a plant  to  be  constructed 
or  subsystem  interfaces  on  a software  project.  Other  information  from  the  project  scope  statement  including  project 
deliverables,  project  constraints,  and  project  assumptions  may  also  affect  activity  sequencing.  While  these  effects 
are  often  apparent  in  the  activity  list,  the  product  scope  description  is  generally  reviewed  to  ensure  accuracy. 

6.3.1 .6  Enterprise  Environmental  Factors 

Described  in  Section  2.1.5.  Enterprise  environmental  factors  that  influence  the  Sequence  Activities  process 
include,  but  are  not  limited  to: 

• Government  or  industry  standards, 

• Project  management  information  system  (PMIS), 

• Scheduling  tool,  and 

• Company  work  authorization  systems. 
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6.3.1 .7  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  can  influence  the  Sequence  Activities  process 
include,  but  are  not  limited  to:  project  files  from  the  corporate  knowledge  base  used  for  scheduling  methodology, 
existing  formal  and  informal  activity  planning-related  policies,  procedures,  and  guidelines,  such  as  the  scheduling 
methodology  that  are  considered  in  developing  logical  relationships,  and  templates  that  can  be  used  to  expedite  the 
preparation  of  networks  of  project  activities.  Related  activity  attributes  information  in  templates  can  also  contain 
additional  descriptive  information  useful  in  sequencing  activities. 

6.3.2  Sequence  Activities:  Tools  and  Techniques 
6.3.2.1  Precedence  Diagramming  Method 

The  precedence  diagramming  method  (PDM)  is  a technique  used  for  constructing  a schedule  model  in  which 
activities  are  represented  by  nodes  and  are  graphically  linked  by  one  or  more  logical  relationships  to  show  the 
sequence  in  which  the  activities  are  to  be  performed.  Activity-on-node  (AON)  is  one  method  of  representing  a 
precedence  diagram.  This  is  the  method  used  by  most  project  management  software  packages. 

PDM  includes  four  types  of  dependencies  or  logical  relationships.  A predecessor  activity  is  an  activity  that 
logically  comes  before  a dependent  activity  in  a schedule.  A successor  activity  is  a dependent  activity  that  logically 
comes  after  another  activity  in  a schedule.  These  relationships  are  defined  below  and  are  illustrated  in  Figure  6-9: 

• Finish-to-start  (FS).  A logical  relationship  in  which  a successor  activity  cannot  start  until  a predecessor 
activity  has  finished.  Example:  The  awards  ceremony  (successor)  cannot  start  until  the  race  (predecessor) 
has  finished. 

• Finish-to-finish  (FF).  A logical  relationship  in  which  a successor  activity  cannot  finish  until  a predecessor 
activity  has  finished.  Example:  Writing  a document  (predecessor)  is  required  to  finish  before  editing  the 
document  (successor)  can  finish. 

• Start-to-start  (SS).  A logical  relationship  in  which  a successor  activity  cannot  start  until  a predecessor 
activity  has  started.  Example:  Level  concrete  (successor)  cannot  begin  until  pour  foundation  (predecessor) 
begins. 

• Start-to-finish  (SF).  A logical  relationship  in  which  a successor  activity  cannot  finish  until  a predecessor 
activity  has  started.  Example:  The  first  security  guard  shift  (successor)  cannot  finish  until  the  second 
security  guard  shift  (predecessor)  starts. 
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In  PDM,  finish-to-start  is  the  most  commonly  used  type  of  precedence  relationship.  The  start-to-finish  relationship 
is  very  rarely  used  but  is  included  to  present  a complete  list  of  the  PDM  relationship  types. 


Figure  6-9.  Precedence  Diagramming  Method  (PDM)  Relationship  Types 


6.3.2.2  Dependency  Determination 

Dependencies  may  be  characterized  by  the  following  attributes:  mandatory  or  discretionary,  internal  or  external, 
as  described  below.  Dependency  has  four  attributes,  but  two  can  be  applicable  at  the  same  time  in  following 
ways:  mandatory  external  dependencies,  mandatory  internal  dependencies,  discretionary  external  dependencies, 
or  discretionary  internal  dependencies. 

• Mandatory  dependencies.  Mandatory  dependencies  are  those  that  are  legally  or  contractually  required 
or  inherent  in  the  nature  of  the  work.  Mandatory  dependencies  often  involve  physical  limitations,  such 
as  on  a construction  project,  where  it  is  impossible  to  erect  the  superstructure  until  after  the  foundation 
has  been  built,  or  on  an  electronics  project,  where  a prototype  has  to  be  built  before  it  can  be  tested. 
Mandatory  dependencies  are  also  sometimes  referred  to  as  hard  logic  or  hard  dependencies.  Technical 
dependencies  may  not  be  mandatory.  The  project  team  determines  which  dependencies  are  mandatory 
during  the  process  of  sequencing  the  activities.  Mandatory  dependencies  should  not  be  confused  with 
assigning  schedule  constraints  in  the  scheduling  tool. 
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• Discretionary  dependencies.  Discretionary  dependencies  are  sometimes  referred  to  as  preferred  logic, 
preferential  logic,  or  soft  logic.  Discretionary  dependencies  are  established  based  on  knowledge  of  best 
practices  within  a particular  application  area  or  some  unusual  aspect  of  the  project  where  a specific 
sequence  is  desired,  even  though  there  may  be  other  acceptable  sequences.  Discretionary  dependencies 
should  be  fully  documented  since  they  can  create  arbitrary  total  float  values  and  can  limit  later  scheduling 
options.  When  fast  tracking  techniques  are  employed,  these  discretionary  dependencies  should  be 
reviewed  and  considered  for  modification  or  removal.  The  project  team  determines  which  dependencies 
are  discretionary  during  the  process  of  sequencing  the  activities. 

• External  dependencies.  External  dependencies  involve  a relationship  between  project  activities  and 
non-project  activities.  These  dependencies  are  usually  outside  the  project  team’s  control.  For  example, 
the  testing  activity  in  a software  project  may  be  dependent  on  the  delivery  of  hardware  from  an  external 
source,  or  governmental  environmental  hearings  may  need  to  be  held  before  site  preparation  can  begin 
on  a construction  project.  The  project  management  team  determines  which  dependencies  are  external 
during  the  process  of  sequencing  the  activities. 

• Internal  dependencies.  Internal  dependencies  involve  a precedence  relationship  between  project 
activities  and  are  generally  inside  the  project  team’s  control.  For  example,  if  the  team  cannot  test  a 
machine  until  they  assemble  it,  this  is  an  internal  mandatory  dependency.  The  project  management  team 
determines  which  dependencies  are  internal  during  the  process  of  sequencing  the  activities. 

6.3.2.3  Leads  and  Lags 

A lead  is  the  amount  of  time  whereby  a successor  activity  can  be  advanced  with  respect  to  a predecessor 
activity.  For  example,  on  a project  to  construct  a new  office  building,  the  landscaping  could  be  scheduled  to  start 
two  weeks  prior  to  the  scheduled  punch  list  completion.  This  would  be  shown  as  a finish-to-start  with  a two-week 
lead  as  shown  in  Figure  6-10.  Lead  is  often  represented  as  a negative  value  for  lag  in  scheduling  software. 
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Figure  6-10.  Examples  of  Lead  and  Lag 
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A lag  is  the  amount  of  time  whereby  a successor  activity  will  be  delayed  with  respect  to  a predecessor  activity. 
For  example,  a technical  writing  team  may  begin  editing  the  draft  of  a large  document  15  days  after  they  begin 
writing  it.  This  can  be  shown  as  a start-to-start  relationship  with  a 15-day  lag  as  shown  in  Figure  6-10.  Lag  can 
also  be  represented  in  project  schedule  network  diagrams  as  shown  in  Figure  6-1 1 in  the  relationship  between 
activities  H and  I,  as  indicated  by  the  nomenclature  SS+10  (start-to-start  plus  10  days  lag)  even  though  offset  is 
not  shown  relative  to  a timescale. 

The  project  management  team  determines  the  dependencies  that  may  require  a lead  or  a lag  to  accurately 
define  the  logical  relationship.  The  use  of  leads  and  lags  should  not  replace  schedule  logic.  Activities  and  their 
related  assumptions  should  be  documented. 

6.3.3  Sequence  Activities:  Outputs 
6.3.3.1  Project  Schedule  Network  Diagrams 

A project  schedule  network  diagram  is  a graphical  representation  of  the  logical  relationships,  also  referred  to  as 
dependencies,  among  the  project  schedule  activities.  Figure  6-1 1 illustrates  a project  schedule  network  diagram.  A 
project  schedule  network  diagram  is  produced  manually  or  by  using  project  management  software.  It  can  include 
full  project  details,  or  have  one  or  more  summary  activities.  A summary  narrative  can  accompany  the  diagram  and 
describe  the  basic  approach  used  to  sequence  the  activities.  Any  unusual  activity  sequences  within  the  network 
should  be  fully  described  within  the  narrative. 
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Figure  6-11.  Project  Schedule  Network  Diagram 


6.3.3.2  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Activity  lists, 

• Activity  attributes, 

• Milestone  list,  and 

• Risk  register. 


6.4  Estimate  Activity  Resources 

Estimate  Activity  Resources  is  the  process  of  estimating  the  type  and  quantities  of  material,  human 
resources,  equipment,  or  supplies  required  to  perform  each  activity.  The  key  benefit  of  this  process  is  that  it 
identifies  the  type,  quantity,  and  characteristics  of  resources  required  to  complete  the  activity  which  allows 
more  accurate  cost  and  duration  estimates.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are 
depicted  in  Figure  6-1 2.  Figure  6-1 3 depicts  the  data  flow  diagram  of  the  process. 
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Figure  6-12.  Estimate  Activity  Resources:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  6-13.  Estimate  Activity  Resources  Data  Flow  Diagram 
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The  Estimate  Activity  Resources  process  is  closely  coordinated  with  the  Estimate  Costs  process  (Section  7.2). 

For  example: 

• A construction  project  team  will  need  to  be  familiar  with  local  building  codes.  Such  knowledge  is  often 
readily  available  from  local  sellers.  However,  if  the  local  labor  pool  lacks  experience  with  unusual  or 
specialized  construction  techniques,  the  additional  cost  for  a consultant  may  be  the  most  effective  way 
to  secure  knowledge  of  the  local  building  codes. 

• An  automotive  design  team  will  need  to  be  familiar  with  the  latest  in  automated  assembly  techniques. 
The  requisite  knowledge  might  be  obtained  by  hiring  a consultant,  by  sending  a designer  to  a seminar  on 
robotics,  or  by  including  someone  from  manufacturing  as  a member  of  the  project  team. 

6.4.1  Estimate  Activity  Resources:  Inputs 

6.4.1 .1  Schedule  Management  Plan 

Described  in  Section  6.1 .3.1 . The  schedule  management  plan  identifies  the  level  of  accuracy  and  the  units  of 

measure  for  the  resources  to  be  estimated. 

6.4.1 .2  Activity  List 

Described  in  Section  6.2. 3.1 . The  activity  list  identifies  the  activities  which  will  need  resources. 

6.4.1 .3  Activity  Attributes 

Described  in  Section  6. 2.3. 2.  The  activity  attributes  provide  the  primary  data  input  for  use  in  estimating  those 

resources  required  for  each  activity  in  the  activity  list. 
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6.4.1 .4  Resource  Calendars 

Described  in  Sections  9. 2. 3. 2 and  1 2. 2. 3. 3.  A resource  calendar  is  a calendar  that  identifies  the  working 
days  and  shifts  on  which  each  specific  resource  is  available.  Information  on  which  resources  (such  as  human 
resources,  equipment,  and  material)  are  potentially  available  during  a planned  activity  period,  is  used  for 
estimating  resource  utilization.  Resource  calendars  specify  when  and  how  long  identified  project  resources 
will  be  available  during  the  project.  This  information  may  be  at  the  activity  or  project  level.  This  knowledge 
includes  consideration  of  attributes  such  as  resource  experience  and/or  skill  level,  as  well  as  various 
geographical  locations  from  which  the  resources  originate  and  when  they  may  be  available. 

6.4.1 .5  Risk  Register 

Described  in  Section  11.2.3.1.  Risk  events  may  impact  resource  selection  and  availability.  Updates  to  the  risk 
register  are  included  with  project  documents  updates,  described  in  Section  1 1 .5.3.2,  from  Plan  Risk  Responses. 

6.4.1 .6  Activity  Cost  Estimates 

Described  in  Section  7.2. 3.1 . The  cost  of  resources  may  impact  resource  selection. 

6.4.1 .7  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  The  enterprise  environmental  factors  that  can  influence  the  Estimate  Activity 
Resources  process  include,  but  are  not  limited  to,  resource  location,  availability,  and  skills. 

6.4.1 .8  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  can  influence  the  Estimate  Activity  Resources 
process  include,  but  are  not  limited  to: 

• Policies  and  procedures  regarding  staffing, 

• Policies  and  procedures  relating  to  rental  and  purchase  of  supplies  and  equipment,  and 

• Historical  information  regarding  types  of  resources  used  for  similar  work  on  previous  projects. 
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6.4.2  Estimate  Activity  Resources:  Tools  and  Techniques 

6.4.2.1  Expert  Judgment 

Expert  judgment  is  often  required  to  assess  the  resource-related  inputs  to  this  process.  Any  group  or  person 
with  specialized  knowledge  in  resource  planning  and  estimating  can  provide  such  expertise. 

6.4.2.2  Alternative  Analysis 

Many  schedule  activities  have  alternative  methods  of  accomplishment.  They  include  using  various  levels  of 
resource  capability  or  skills,  different  size  or  type  of  machines,  different  tools  (hand  versus  automated),  and  make- 
rent-or-buy  decisions  regarding  the  resource  (Section  12.1.3.5). 

6.4.2.3  Published  Estimating  Data 

Several  organizations  routinely  publish  updated  production  rates  and  unit  costs  of  resources  for  an  extensive 
array  of  labor  trades,  material,  and  equipment  for  different  countries  and  geographical  locations  within  countries. 

6.4.2.4  Bottom-Up  Estimating 

Bottom-up  estimating  is  a method  of  estimating  project  duration  or  cost  by  aggregating  the  estimates  of  the 
lower-level  components  of  the  WBS.  When  an  activity  cannot  be  estimated  with  a reasonable  degree  of  confidence, 
the  work  within  the  activity  is  decomposed  into  more  detail.  The  resource  needs  are  estimated.  These  estimates 
are  then  aggregated  into  a total  quantity  for  each  of  the  activity’s  resources.  Activities  may  or  may  not  have 
dependencies  between  them  that  can  affect  the  application  and  use  of  resources.  If  there  are  dependencies,  this 
pattern  of  resource  usage  is  reflected  and  documented  in  the  estimated  requirements  of  the  activity. 

6.4.2.5  Project  Management  Software 

Project  management  software,  such  as  a scheduling  software  tool,  has  the  capability  to  help  plan,  organize,  and 
manage  resource  pools  and  develop  resource  estimates.  Depending  on  the  sophistication  of  the  software,  resource 
breakdown  structures,  resource  availability,  resource  rates,  and  various  resource  calendars  can  be  defined  to  assist 
in  optimizing  resource  utilization. 
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6.4.3  Estimate  Activity  Resources:  Outputs 

6.4.3.1  Activity  Resource  Requirements 

Activity  resource  requirements  identify  the  types  and  quantities  of  resources  required  for  each  activity  in  a work 
package.  These  requirements  then  can  be  aggregated  to  determine  the  estimated  resources  for  each  work  package 
and  each  work  period.  The  amount  of  detail  and  the  level  of  specificity  of  the  resource  requirement  descriptions 
can  vary  by  application  area.  The  resource  requirements  documentation  for  each  activity  can  include  the  basis  of 
estimate  for  each  resource,  as  well  as  the  assumptions  that  were  made  in  determining  which  types  of  resources 
are  applied,  their  availability,  and  what  quantities  are  used. 

6.4.3.2  Resource  Breakdown  Structure 

The  resource  breakdown  structure  is  a hierarchical  representation  of  resources  by  category  and  type.  Examples 
of  resource  categories  include  labor,  material,  equipment,  and  supplies.  Resource  types  may  include  the  skill  level, 
grade  level,  or  other  information  as  appropriate  to  the  project.  The  resource  breakdown  structure  is  useful  for 
organizing  and  reporting  project  schedule  data  with  resource  utilization  information. 

6.4.3.3  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Activity  list, 

• Activity  attributes,  and 

• Resource  calendars. 

6.5  Estimate  Activity  Durations 

Estimate  Activity  Durations  is  the  process  of  estimating  the  number  of  work  periods  needed  to  complete 
individual  activities  with  estimated  resources.  The  key  benefit  of  this  process  is  that  it  provides  the  amount  of  time 
each  activity  will  take  to  complete,  which  is  a major  input  into  the  Develop  Schedule  process.  The  inputs,  tools  and 
techniques,  and  outputs  of  this  process  are  depicted  in  Figure  6-14.  Figure  6-15  depicts  the  data  flow  diagram  of 
the  process. 
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Figure  6-14.  Estimate  Activity  Durations:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  6-15.  Estimate  Activity  Durations  Data  Flow  Diagram 
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Estimating  activity  durations  uses  information  on  activity  scope  of  work,  required  resource  types,  estimated 
resource  quantities,  and  resource  calendars.  The  inputs  of  the  estimates  of  activity  duration  originate  from  the 
person  or  group  on  the  project  team  who  is  most  familiar  with  the  nature  of  the  work  in  the  specific  activity.  The 
duration  estimate  is  progressively  elaborated,  and  the  process  considers  the  quality  and  availability  of  the  input 
data.  For  example,  as  more  detailed  and  precise  data  is  available  about  the  project  engineering  and  design  work, 
the  accuracy  of  the  duration  estimates  improves.  Thus,  the  duration  estimate  can  be  assumed  to  be  progressively 
more  accurate  and  of  better  quality. 

The  Estimate  Activity  Durations  process  requires  an  estimation  of  the  amount  of  work  effort  required  to  complete 
the  activity  and  the  amount  of  available  resources  estimated  to  complete  the  activity.  These  estimates  are  used  to 
approximate  the  number  of  work  periods  (activity  duration)  needed  to  complete  the  activity  using  the  appropriate 
project  and  resource  calendars.  All  data  and  assumptions  that  support  duration  estimating  are  documented  for 
each  estimate  of  activity  duration. 

6.5.1  Estimate  Activity  Durations:  Inputs 

6.5.1 .1  Schedule  Management  Plan 

Described  in  Section  6.1 .3.1 . The  schedule  management  plan  defines  the  method  used  and  the  level  of  accuracy 
along  with  other  criteria  required  to  estimate  activity  durations  including  the  project  update  cycle. 

6.5.1 .2  Activity  List 

Described  in  Section  6.2. 3.1 . The  activity  list  identifies  the  activities  that  will  need  duration  estimates. 

6.5.1 .3  Activity  Attributes 

Described  in  Section  6.2. 3.2.  The  activity  attributes  provide  the  primary  data  input  for  use  in  estimating  durations 
required  for  each  activity  in  the  activity  list. 

6.5.1 .4  Activity  Resource  Requirements 

Described  in  Section  6.4. 3.1  .The  estimated  activity  resource  requirements  will  have  an  effect  on  the  duration  of 
the  activity,  since  the  level  to  which  the  resources  assigned  to  the  activity  meet  the  requirements  will  significantly 
influence  the  duration  of  most  activities.  For  example,  if  additional  or  lower-skilled  resources  are  assigned  to  an 
activity,  there  may  be  reduced  efficiency  or  productivity  due  to  increased  communication,  training,  and  coordination 
needs  leading  to  a longer  duration  estimate. 
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6.5.1 .5  Resource  Calendars 

Described  in  Section  6.4. 1.4.  The  resource  calendars  influence  the  duration  of  schedule  activities  due  to  the 
availability  of  specific  resources,  type  of  resources,  and  resources  with  specific  attributes.  For  example,  when  staff 
members  are  assigned  to  an  activity  on  a full-time  basis,  in  general,  a skilled  staff  member  can  be  expected  to 
complete  a given  activity  in  less  time  than  a relatively  less-skilled  staff  member. 

6.5.1 .6  Project  Scope  Statement 

Described  in  Section  5.3. 3.1  .The  assumptions  and  constraints  from  the  project  scope  statement  are  considered 
when  estimating  the  activity  durations.  Examples  of  assumptions  include,  but  are  not  limited  to: 

• Existing  conditions, 

• Availability  of  information,  and 

• Length  of  the  reporting  periods. 

Examples  of  constraints  include,  but  are  not  limited  to: 

• Available  skilled  resources,  and 

• Contract  terms  and  requirements. 

6.5.1 .7  Risk  Register 

Described  in  Section  1 1 .2.3.1 . The  risk  register  provides  the  list  of  risks,  along  with  the  results  of  risk  analysis 
and  risk  response  planning.  Updates  to  the  risk  register  are  included  with  project  document  updates  described  in 
Section  11.5.3.2. 

6.5.1 .8  Resource  Breakdown  Structure 

Described  in  Section  6. 4.3. 2.  The  resource  breakdown  structure  provides  a hierarchical  structure  of  the  identified 
resources  by  resource  category  and  resource  type. 
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6.5.1 .9  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  The  enterprise  environmental  factors  that  can  influence  the  Estimate  Activity 
Durations  process  include,  but  are  not  limited  to: 

• Duration  estimating  databases  and  other  reference  data, 

• Productivity  metrics, 

• Published  commercial  information,  and 

• Location  of  team  members. 

6 

6.5.1.10  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  can  influence  the  Estimate  Activity  Durations 
process  include,  but  are  not  limited  to: 

• Historical  duration  information, 

• Project  calendars, 

• Scheduling  methodology,  and 

• Lessons  learned. 

6.5.2  Estimate  Activity  Durations:  Tools  and  Techniques 

6.5.2.1  Expert  Judgment 

Expert  judgment,  guided  by  historical  information,  can  provide  duration  estimate  information  or  recommended 
maximum  activity  durations  from  prior  similar  projects.  Expert  judgment  can  also  be  used  to  determine  whether  to 
combine  methods  of  estimating  and  how  to  reconcile  differences  between  them. 

6.5.2.2  Analogous  Estimating 

Analogous  estimating  is  a technique  for  estimating  the  duration  or  cost  of  an  activity  or  a project  using 
historical  data  from  a similar  activity  or  project.  Analogous  estimating  uses  parameters  from  a previous, 
similar  project,  such  as  duration,  budget,  size,  weight,  and  complexity,  as  the  basis  for  estimating  the  same 
parameter  or  measure  for  a future  project.  When  estimating  durations,  this  technique  relies  on  the  actual 
duration  of  previous,  similar  projects  as  the  basis  for  estimating  the  duration  of  the  current  project.  It  is  a 
gross  value  estimating  approach,  sometimes  adjusted  for  known  differences  in  project  complexity.  Analogous 
duration  estimating  is  frequently  used  to  estimate  project  duration  when  there  is  a limited  amount  of  detailed 
information  about  the  project. 
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Analogous  estimating  is  generally  less  costly  and  less  time  consuming  than  other  techniques,  but  it  is  also 
less  accurate.  Analogous  duration  estimates  can  be  applied  to  a total  project  or  to  segments  of  a project  and  may 
be  used  in  conjunction  with  other  estimating  methods.  Analogous  estimating  is  most  reliable  when  the  previous 
activities  are  similar  in  fact  and  not  just  in  appearance,  and  the  project  team  members  preparing  the  estimates 
have  the  needed  expertise. 

6.5.2.3  Parametric  Estimating 

Parametric  estimating  is  an  estimating  technique  in  which  an  algorithm  is  used  to  calculate  cost  or  duration 
based  on  historical  data  and  project  parameters.  Parametric  estimating  uses  a statistical  relationship  between 
historical  data  and  other  variables  (e.g.,  square  footage  in  construction)  to  calculate  an  estimate  for  activity 
parameters,  such  as  cost,  budget,  and  duration. 

Activity  durations  can  be  quantitatively  determined  by  multiplying  the  quantity  of  work  to  be  performed  by  labor 
hours  per  unit  of  work.  For  example,  activity  duration  on  a design  project  is  estimated  by  the  number  of  drawings 
multiplied  by  the  number  of  labor  hours  per  drawing,  or  on  a cable  installation,  the  meters  of  cable  multiplied  by  the 
number  of  labor  hours  per  meter.  For  example,  if  the  assigned  resource  is  capable  of  installing  25  meters  of  cable 
per  hour,  the  duration  required  to  install  1 ,000  meters  is  40  hours.  (1 ,000  meters  divided  by  25  meters  per  hour). 

This  technique  can  produce  higher  levels  of  accuracy  depending  upon  the  sophistication  and  underlying  data 
built  into  the  model.  Parametric  time  estimates  can  be  applied  to  a total  project  or  to  segments  of  a project,  in 
conjunction  with  other  estimating  methods. 

6.5.2.4  Three-Point  Estimating 

The  accuracy  of  single-point  activity  duration  estimates  may  be  improved  by  considering  estimation  uncertainty 
and  risk.  This  concept  originated  with  the  program  evaluation  and  review  technique  (PERT).  PERT  uses  three 
estimates  to  define  an  approximate  range  for  an  activity’s  duration: 

• Most  likely  (tM).  This  estimate  is  based  on  the  duration  of  the  activity,  given  the  resources  likely  to  be 
assigned,  their  productivity,  realistic  expectations  of  availability  for  the  activity,  dependencies  on  other 
participants,  and  interruptions. 

• Optimistic  (tO).  The  activity  duration  based  on  analysis  of  the  best-case  scenario  for  the  activity. 

• Pessimistic  (tF).  The  activity  duration  based  on  analysis  of  the  worst-case  scenario  for  the  activity. 
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Depending  on  the  assumed  distribution  of  values  within  the  range  of  the  three  estimates  the  expected  duration, 
tE,  can  be  calculated  using  a formula.  Two  commonly  used  formulas  are  triangular  and  beta  distributions.  The 
formulas  are: 

• Triangular  Distribution.  tE  = (tO  + tM+tP)/  3 

• Beta  Distribution  (from  the  traditional  PERT  technique).  tE  = (tO  + 4tM  + tP)l  6 

Duration  estimates  based  on  three  points  with  an  assumed  distribution  provide  an  expected  duration  and  clarify 
the  range  of  uncertainty  around  the  expected  duration. 

6.5.2.5  Group  Decision-Making  Techniques 

Team-based  approaches,  such  as  brainstorming,  the  Delphi  or  nominal  group  techniques,  are  useful  for  engaging 
team  members  to  improve  estimate  accuracy  and  commitment  to  the  emerging  estimates.  By  involving  a structured 
group  of  people  who  are  close  to  the  technical  execution  of  work  in  the  estimation  process,  additional  information 
is  gained  and  more  accurate  estimates  obtained.  Additionally,  when  people  are  involved  in  the  estimation  process, 
their  commitment  towards  meeting  the  resulting  estimates  increases. 

6.5.2.6  Reserve  Analysis 

Duration  estimates  may  include  contingency  reserves,  sometimes  referred  to  as  time  reserves  or  buffers, 
into  the  project  schedule  to  account  for  schedule  uncertainty.  Contingency  reserves  are  the  estimated  duration 
within  the  schedule  baseline,  which  is  allocated  for  identified  risks  that  are  accepted  and  for  which  contingent  or 
mitigation  responses  are  developed.  Contingency  reserves  are  associated  with  the  “known-unknowns,”  which  may 
be  estimated  to  account  for  this  unknown  amount  of  rework.  The  contingency  reserve  may  be  a percentage  of  the 
estimated  activity  duration,  a fixed  number  of  work  periods,  or  may  be  developed  by  using  quantitative  analysis 
methods  such  as  Monte  Carlo  simulation  (Section  11.4.2.2).  Contingency  reserves  may  be  separated  from  the 
individual  activities  and  aggregated  into  buffers  as  shown  in  Figure  6-19. 

As  more  precise  information  about  the  project  becomes  available,  the  contingency  reserve  may  be  used, 
reduced,  or  eliminated.  Contingency  should  be  clearly  identified  in  schedule  documentation. 

Estimates  may  also  be  produced  for  the  amount  of  management  reserve  of  time  for  the  project.  Management 
reserves  are  a specified  amount  of  the  project  duration  withheld  for  management  control  purposes  and  are 
reserved  for  unforeseen  work  that  is  within  scope  of  the  project.  Management  reserves  are  intended  to  address  the 
“unknown-unknowns”  that  can  affect  a project.  Management  reserve  is  not  included  in  the  schedule  baseline,  but 
it  is  part  of  the  overall  project  duration  requirements.  Depending  on  contract  terms,  use  of  management  reserves 
may  require  a change  to  the  schedule  baseline. 
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6.5.3  Estimate  Activity  Durations:  Outputs 

6.5.3.1  Activity  Duration  Estimates 

Activity  duration  estimates  are  quantitative  assessments  of  the  likely  number  of  time  periods  that  are  required 
to  complete  an  activity.  Duration  estimates  do  not  include  any  lags  as  described  in  Section  6.3. 2.3.  Activity  duration 
estimates  may  include  some  indication  of  the  range  of  possible  results.  For  example: 

• 2 weeks  ± 2 days,  which  indicates  that  the  activity  will  take  at  least  eight  days  and  not  more  than  twelve 
(assuming  a five-day  workweek);  and 

• 1 5 % probability  of  exceeding  three  weeks,  which  indicates  a high  probability — 85  % — that  the  activity 
will  take  three  weeks  or  less. 

6.5.3.2  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Activity  attributes;  and 

• Assumptions  made  in  developing  the  activity  duration  estimate,  such  as  skill  levels  and  availability, 
as  well  as  a basis  of  estimates  for  durations. 

6.6  Develop  Schedule 

Develop  Schedule  is  the  process  of  analyzing  activity  sequences,  durations,  resource  requirements,  and 
schedule  constraints  to  create  the  project  schedule  model.  The  key  benefit  of  this  process  is  that  by  entering 
schedule  activities,  durations,  resources,  resource  availabilities,  and  logical  relationships  into  the  scheduling  tool,  it 
generates  a schedule  model  with  planned  dates  for  completing  project  activities.  The  inputs,  tools  and  techniques, 
and  outputs  of  this  process  are  depicted  in  Figure  6-16.  Figure  6-17  depicts  the  data  flow  diagram  of  the  process. 
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Figure  6-16  Develop  Schedule:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  6-17.  Develop  Schedule  Data  Flow  Diagram 
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Developing  an  acceptable  project  schedule  is  often  an  iterative  process.  The  schedule  model  is  used  to 
determine  the  planned  start  and  finish  dates  for  project  activities  and  milestones  based  on  the  accuracy  of  the 
inputs.  Schedule  development  can  require  the  review  and  revision  of  duration  estimates  and  resource  estimates  to 
create  the  project  schedule  model  to  establish  an  approved  project  schedule  that  can  serve  as  a baseline  to  track 
progress.  Once  the  activity  start  and  finish  dates  have  been  determined,  it  is  common  to  have  project  staff  assigned 
to  the  activities  review  their  assigned  activities  and  confirm  that  the  start  and  finish  dates  present  no  conflict  with 
resource  calendars  or  assigned  activities  in  other  projects  or  tasks  and  thus  are  still  valid.  As  work  progresses, 
revising  and  maintaining  the  project  schedule  model  to  sustain  a realistic  schedule  continues  throughout  the 
duration  of  the  project,  as  described  in  Section  6.7. 

For  more  specific  information  regarding  scheduling,  refer  to  the  Practice  Standard  for  Scheduling. 

6.6.1  Develop  Schedule:  Inputs 

6.6.1 .1  Schedule  Management  Plan 

Described  in  Section  6.1 .3.1 . The  schedule  management  plan  identifies  the  scheduling  method  and  tool  used  to 
create  the  schedule,  and  how  the  schedule  is  to  be  calculated. 

6.6.1 .2  Activity  List 

Described  in  Section  6.2. 3.1 . The  activity  list  identifies  the  activities  that  will  be  included  in  the  schedule  model. 

6.6.1 .3  Activity  Attributes 

Described  in  Section  6.2. 3.2.  The  activity  attributes  provide  the  details  used  to  build  the  schedule  model. 

6.6.1 .4  Project  Schedule  Network  Diagrams 

Described  in  Section  6.3. 3.1.  The  project  schedule  network  diagrams  contain  the  logical  relationships  of 
predecessors  and  successors  that  will  be  used  to  calculate  the  schedule. 
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6.6.1 .5  Activity  Resource  Requirements 

Described  in  Section  6. 4.3.1.  The  activity  resource  requirements  identify  the  types  and  quantities  of  resources 
required  for  each  activity  used  to  create  the  schedule  model. 

6.6.1 .6  Resource  Calendars 

Described  in  Sections  9. 2.3. 2 and  12.2.3.3.  The  resource  calendars  contain  information  on  the  availability  of 
resources  during  the  project. 

6 

6.6.1 .7  Activity  Duration  Estimates 

Described  in  Section  6.5. 3.1 . The  activity  duration  estimates  contain  the  quantitative  assessments  of  the  likely 
number  of  work  periods  that  will  be  required  to  complete  an  activity  that  will  be  used  to  calculate  the  schedule. 

6.6.1 .8  Project  Scope  Statement 

Described  in  Section  5. 3.3.1  .The  project  scope  statement  contains  assumptions  and  constraints  that  can  impact 
the  development  of  the  project  schedule. 

6.6.1 .9  Risk  Register 

Described  in  Section  1 1 .2.3.1  .The  risk  register  provides  the  details  of  all  identified  risks  and  their  characteristics 
that  affect  the  schedule  model. 

6.6.1 .10  Project  Staff  Assignments 

Described  in  Section  9. 2.3.1.  The  project  staff  assignments  specify  which  resources  are  assigned  to  each 
activity. 

6.6.1.11  Resource  Breakdown  Structure 

Described  in  Section  6.4. 3.2.  The  resource  breakdown  structure  provides  the  details  by  which  resource  analysis 
and  organizational  reporting  can  be  done. 
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6.6.1.12  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  The  enterprise  environmental  factors  include,  but  are  not  limited  to: 

• Standards, 

• Communication  channels,  and 

• Scheduling  tool  to  be  used  in  developing  the  schedule  model. 

6.6.1.13  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  can  influence  the  Develop  Schedule  process 
include,  but  are  not  limited  to:  scheduling  methodology  and  project  calendar(s). 

6.6.2  Develop  Schedule:  Tools  and  Techniques 

6.6.2.1  Schedule  Network  Analysis 

Schedule  network  analysis  is  a technique  that  generates  the  project  schedule  model.  It  employs  various  analytical 
techniques,  such  as  critical  path  method,  critical  chain  method,  what-if  analysis,  and  resource  optimization 
techniques  to  calculate  the  early  and  late  start  and  finish  dates  for  the  uncompleted  portions  of  project  activities. 
Some  network  paths  may  have  points  of  path  convergence  or  path  divergence  that  can  be  identified  and  used  in 
schedule  compression  analysis  or  other  analyses. 

6.6.2.2  Critical  Path  Method 

The  critical  path  method,  which  is  a method  used  to  estimate  the  minimum  project  duration  and  determine  the 
amount  of  scheduling  flexibility  on  the  logical  network  paths  within  the  schedule  model.  This  schedule  network 
analysis  technique  calculates  the  early  start,  early  finish,  late  start,  and  late  finish  dates  for  all  activities  without 
regard  for  any  resource  limitations  by  performing  a forward  and  backward  pass  analysis  through  the  schedule 
network,  as  shown  in  Figure  6-1 8.  In  this  example  the  longest  path  includes  activities  A,  C,  and  D,  and,  therefore,  the 
sequence  of  A-C-D  is  the  critical  path. The  critical  path  is  the  sequence  of  activities  that  represents  the  longest  path 
through  a project,  which  determines  the  shortest  possible  project  duration.  The  resulting  early  and  late  start  and 
finish  dates  are  not  necessarily  the  project  schedule,  rather  they  indicate  the  time  periods  within  which  the  activity 
could  be  executed,  using  the  parameters  entered  in  the  schedule  model  for  activity  durations,  logical  relationships, 
leads,  lags,  and  other  known  constraints.  The  critical  path  method  is  used  to  calculate  the  amount  of  scheduling 
flexibility  on  the  logical  network  paths  within  the  schedule  model. 
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On  any  network  path,  the  schedule  flexibility  is  measured  by  the  amount  of  time  that  a schedule  activity  can 
be  delayed  or  extended  from  its  early  start  date  without  delaying  the  project  finish  date  or  violating  a schedule 
constraint,  and  is  termed  “total  float.”  A CPM  critical  path  is  normally  characterized  by  zero  total  float  on  the 
critical  path.  As  implemented  with  PDM  sequencing,  critical  paths  may  have  positive,  zero,  or  negative  total 
float  depending  on  constraints  applied.  Any  activity  on  the  critical  path  is  called  a critical  path  activity.  Positive 
total  float  is  caused  when  the  backward  pass  is  calculated  from  a schedule  constraint  that  is  later  than  the 
early  finish  date  that  has  been  calculated  during  forward  pass  calculation.  Negative  total  float  is  caused  when  a 
constraint  on  the  late  dates  is  violated  by  duration  and  logic.  Schedule  networks  may  have  multiple  near-critical 
paths.  Many  software  packages  allow  the  user  to  define  the  parameters  used  to  determine  the  critical  path(s). 
Adjustments  to  activity  durations  (if  more  resources  or  less  scope  can  be  arranged),  logical  relationships  (if  the 
relationships  were  discretionary  to  begin  with),  leads  and  lags,  or  other  schedule  constraints  may  be  necessary 
to  produce  network  paths  with  a zero  or  positive  total  float.  Once  the  total  float  for  a network  path  has  been 
calculated,  then  the  free  float — the  amount  of  time  that  a schedule  activity  can  be  delayed  without  delaying  the 
early  start  date  of  any  successor  or  violating  a schedule  constraint — can  also  be  determined.  For  example  the 
free  float  for  Activity  B,  in  Figure  6-1 8,  is  5 days. 


Figure  6-18.  Example  of  Critical  Path  Method 
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6.6.2.3  Critical  Chain  Method 

The  critical  chain  method  (CCM)  is  a schedule  method  that  allows  the  project  team  to  place  buffers  on  any 
project  schedule  path  to  account  for  limited  resources  and  project  uncertainties.  It  is  developed  from  the  critical 
path  method  approach  and  considers  the  effects  of  resource  allocation,  resource  optimization,  resource  leveling, 
and  activity  duration  uncertainty  on  the  critical  path  determined  using  the  critical  path  method.  To  do  so,  the  critical 
chain  method  introduces  the  concept  of  buffers  and  buffer  management.  The  critical  chain  method  uses  activities 
with  durations  that  do  not  include  safety  margins,  logical  relationships,  and  resource  availability  with  statistically 
determined  buffers  composed  of  the  aggregated  safety  margins  of  activities  at  specified  points  on  the  project 
schedule  path  to  account  for  limited  resources  and  project  uncertainties.  The  resource-constrained  critical  path  is 
known  as  the  critical  chain. 

The  critical  chain  method  adds  duration  buffers  that  are  non-work  schedule  activities  to  manage  uncertainty. 
One  buffer,  placed  at  the  end  of  the  critical  chain,  as  shown  in  Figure  6-19,  is  known  as  the  project  buffer  and 
protects  the  target  finish  date  from  slippage  along  the  critical  chain.  Additional  buffers,  known  as  feeding  buffers, 
are  placed  at  each  point  where  a chain  of  dependent  activities  that  are  not  on  the  critical  chain  feeds  into  the  critical 
chain.  Feeding  buffers  thus  protect  the  critical  chain  from  slippage  along  the  feeding  chains.  The  size  of  each  buffer 
should  account  for  the  uncertainty  in  the  duration  of  the  chain  of  dependent  activities  leading  up  to  that  buffer.  Once 
the  buffer  schedule  activities  are  determined,  the  planned  activities  are  scheduled  to  their  latest  possible  planned 
start  and  finish  dates.  Consequently,  instead  of  managing  the  total  float  of  network  paths,  the  critical  chain  method 
focuses  on  managing  the  remaining  buffer  durations  against  the  remaining  durations  of  chains  of  activities. 
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Figure  6-19.  Example  of  Critical  Chain  Method 
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6.6.2.4  Resource  Optimization  Techniques 

Examples  of  resource  optimization  techniques  that  can  be  used  to  adjust  the  schedule  model  due  to  demand 
and  supply  of  resources  include,  but  are  not  limited  to: 

• Resource  leveling.  Atechnique  in  which  start  and  finish  dates  are  adjusted  based  on  resource  constraints 
with  the  goal  of  balancing  demand  for  resources  with  the  available  supply.  Resource  leveling  can  be  used 
when  shared  or  critically  required  resources  are  only  available  at  certain  times,  or  in  limited  quantities, 
or  over-allocated,  such  as  when  a resource  has  been  assigned  to  two  or  more  activities  during  the  same 
time  period,  as  shown  in  Figure  6-20,  or  to  keep  resource  usage  at  a constant  level.  Resource  leveling 
can  often  cause  the  original  critical  path  to  change,  usually  to  increase. 


Activities  Before  Resource  Leveling 


©“ 


Activity  A 


Tom:  8 hrs 
Sue:  8 hrs 


Activity  B Sue:  8 hrs 


Activity  C Tom:  8 hrs 


Day  1 

Day  2 

Day  3 

Tom:  8 hrs 

Sue:  16  hrs 

Tom:  8 hrs 

Activities  After  Resource  Leveling 


Activity  A 


Tom:  8 hrs 
Sue:  8 hrs 


Activity  B Sue:  8 hrs 


Activity  C Tom:  8 hrs 


Day  1 

Day  2 

Day  3 

Tom:  8 hrs 

Sue:  8 hrs 

Sue:  8 hrs 

Tom:  8 hrs 

Figure  6-20.  Resource  Leveling 
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• Resource  Smoothing.  A technique  that  adjusts  the  activities  of  a schedule  model  such  that  the 
requirements  for  resources  on  the  project  do  not  exceed  certain  predefined  resource  limits.  In  resource 
smoothing,  as  opposed  to  resource  leveling,  the  project’s  critical  path  is  not  changed  and  the  completion 
date  may  not  be  delayed.  In  other  words,  activities  may  only  be  delayed  within  their  free  and  total  float. 
Thus  resource  smoothing  may  not  be  able  to  optimize  all  resources. 

6.6.2.5  Modeling  Techniques 

Examples  of  modeling  techniques  include,  but  are  not  limited  to: 

• What-lf  Scenario  Analysis.  What-if  scenario  analysis  is  the  process  of  evaluating  scenarios  in  order 
to  predict  their  effect,  positively  or  negatively,  on  project  objectives.  This  is  an  analysis  of  the  question, 
“What  if  the  situation  represented  by  scenario  ‘X’  happens?”  A schedule  network  analysis  is  performed 
using  the  schedule  to  compute  the  different  scenarios,  such  as  delaying  a major  component  delivery, 
extending  specific  engineering  durations,  or  introducing  external  factors,  such  as  a strike  or  a change  in 
the  permitting  process.  The  outcome  of  the  what-if  scenario  analysis  can  be  used  to  assess  the  feasibility 
of  the  project  schedule  under  adverse  conditions,  and  in  preparing  contingency  and  response  plans  to 
overcome  or  mitigate  the  impact  of  unexpected  situations. 

• Simulation.  Simulation  involves  calculating  multiple  project  durations  with  different  sets  of  activity 
assumptions,  usually  using  probability  distributions  constructed  from  the  three-point  estimates  (described 
in  Section  6.5. 2.4)  to  account  for  uncertainty.  The  most  common  simulation  technique  is  Monte  Carlo 
analysis  (Section  1 1 .4.2.2),  in  which  a distribution  of  possible  activity  durations  is  defined  for  each  activity 
and  used  to  calculate  a distribution  of  possible  outcomes  for  the  total  project. 

6.6.2.6  Leads  and  Lags 

Described  in  Section  6.3. 2.3.  Leads  and  lags  are  refinements  applied  during  network  analysis  to  develop  a 
viable  schedule  by  adjusting  the  start  time  of  the  successor  activities.  Leads  are  used  in  limited  circumstances  to 
advance  a successor  activity  with  respect  to  the  predecessor  activity,  and  lags  are  used  in  limited  circumstances 
where  processes  require  a set  period  of  time  to  elapse  between  the  predecessors  and  successors  without  work  or 
resource  impact. 
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6.6.2.7  Schedule  Compression 

Schedule  compression  techniques  are  used  to  shorten  the  schedule  duration  without  reducing  the  project 
scope,  in  order  to  meet  schedule  constraints,  imposed  dates,  or  other  schedule  objectives.  Schedule  compression 
techniques  include,  but  are  not  limited  to: 

• Crashing.  A technique  used  to  shorten  the  schedule  duration  for  the  least  incremental  cost  by  adding 
resources.  Examples  of  crashing  include  approving  overtime,  bringing  in  additional  resources,  or  paying 
to  expedite  delivery  to  activities  on  the  critical  path.  Crashing  works  only  for  activities  on  the  critical  path 
where  additional  resources  will  shorten  the  activity’s  duration.  Crashing  does  not  always  produce  a viable 
alternative  and  may  result  in  increased  risk  and/or  cost. 

• Fast  tracking.  A schedule  compression  technique  in  which  activities  or  phases  normally  done  in  sequence 
are  performed  in  parallel  for  at  least  a portion  of  their  duration.  An  example  is  constructing  the  foundation 
for  a building  before  completing  all  of  the  architectural  drawings.  Fast  tracking  may  result  in  rework  and 
increased  risk.  Fast  tracking  only  works  if  activities  can  be  overlapped  to  shorten  the  project  duration. 

6.6.2.8  Scheduling  Tool 

Automated  scheduling  tools  contain  the  schedule  model  and  expedite  the  scheduling  process  by  generating 
start  and  finish  dates  based  on  the  inputs  of  activities,  network  diagrams,  resources  and  activity  durations  using 
schedule  network  analysis.  A scheduling  tool  can  be  used  in  conjunction  with  other  project  management  software 
applications  as  well  as  manual  methods. 

6.6.3  Develop  Schedule:  Outputs 
6.6.3.1  Schedule  Baseline 

A schedule  baseline  is  the  approved  version  of  a schedule  model  that  can  be  changed  only  through  formal 
change  control  procedures  and  is  used  as  a basis  for  comparison  to  actual  results.  It  is  accepted  and  approved  by 
the  appropriate  stakeholders  as  the  schedule  baseline  with  baseline  start  dates  and  baseline  finish  dates.  During 
monitoring  and  controlling,  the  approved  baseline  dates  are  compared  to  the  actual  start  and  finish  dates  to  determine 
whether  variances  have  occurred.  The  schedule  baseline  is  a component  of  the  project  management  plan. 
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6.6.3.2  Project  Schedule 

The  outputs  from  a schedule  model  are  schedule  presentations.  The  project  schedule  is  an  output  of  a schedule 
model  that  presents  linked  activities  with  planned  dates,  durations,  milestones,  and  resources.  At  a minimum,  the 
project  schedule  includes  a planned  start  date  and  planned  finish  date  for  each  activity.  If  resource  planning  is  done 
at  an  early  stage,  then  the  project  schedule  remains  preliminary  until  resource  assignments  have  been  confirmed 
and  scheduled  start  and  finish  dates  are  established.  This  process  usually  occurs  no  later  than  the  completion  of  the 
project  management  plan  (Section  4.2. 3.1 ).  A target  project  schedule  model  may  also  be  developed  with  a defined 
target  start  and  target  finish  for  each  activity.  The  project  schedule  presentation  may  be  presented  in  summary 
form,  sometimes  referred  to  as  the  master  schedule  or  milestone  schedule,  or  presented  in  detail.  Although  a 
project  schedule  model  can  be  presented  in  tabular  form,  it  is  more  often  presented  graphically,  using  one  or  more 
of  the  following  formats,  which  are  classified  as  presentations: 

• Bar  charts.  These  charts,  also  known  as  Gantt  charts,  represent  schedule  information  where  activities 
are  listed  on  the  vertical  axis,  dates  are  shown  on  the  horizontal  axis,  and  activity  durations  are  shown 
as  horizontal  bars  placed  according  to  start  and  finish  dates.  Bar  charts  are  relatively  easy  to  read, 
and  are  frequently  used  in  management  presentations.  For  control  and  management  communications, 
the  broader,  more  comprehensive  summary  activity,  sometimes  referred  to  as  a hammock  activity,  is 
used  between  milestones  or  across  multiple  interdependent  work  packages,  and  is  displayed  in  bar 
chart  reports.  An  example  is  the  summary  schedule  portion  of  Figure  6-21  that  is  presented  in  a WBS- 
structured  format. 

• Milestone  charts.  These  charts  are  similar  to  bar  charts,  but  only  identify  the  scheduled  start  or 
completion  of  major  deliverables  and  key  external  interfaces.  An  example  is  the  milestone  schedule 
portion  of  Figure  6-21 . 

• Project  schedule  network  diagrams.  These  diagrams  are  commonly  presented  in  the  activity-on-node 
diagram  format  showing  activities  and  relationships  without  a time  scale,  sometimes  referred  to  as  a 
pure  logic  diagram,  as  shown  in  Figure  6-1 1 , or  presented  in  a time-scaled  schedule  network  diagram 
format  that  is  sometimes  called  a logic  bar  chart,  as  shown  for  the  detailed  schedule  in  Figure  6-21  .These 
diagrams,  with  activity  date  information,  usually  show  both  the  project  network  logic  and  the  project’s 
critical  path  schedule  activities.  This  example  also  shows  how  each  work  package  is  planned  as  a series 
of  related  activities.  Another  presentation  of  the  project  schedule  network  diagram  is  a time-scaled  logic 
diagram.  These  diagrams  include  a time  scale  and  bars  that  represent  the  duration  of  activities  with  the 
logical  relationships.  It  is  optimized  to  show  the  relationships  between  activities  where  any  number  of 
activities  may  appear  on  the  same  line  of  the  diagram  in  sequence. 
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Figure  6-21 . Project  Schedule  Presentations  — Examples 
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Figure  6-21  shows  schedule  presentations  for  a sample  project  being  executed,  with  the  work  in  progress 
reported  through  the  data  date,  a point  in  time  when  the  status  of  the  project  is  recorded,  which  is  sometimes 
also  called  the  as-of  date  or  status  date.  For  a simple  project  schedule  model,  Figure  6-21  reflects  schedule 
presentations  in  the  forms  of  (1)  a milestone  schedule  as  a milestone  chart,  (2)  a summary  schedule  as  a bar 
chart,  and  (3)  a detailed  schedule  as  a project  schedule  network  diagram.  Figure  6-21  also  visually  shows  the 
relationships  among  the  three  different  levels  of  schedule  presentation. 

6.6.3.3  Schedule  Data 

The  schedule  data  for  the  project  schedule  model  is  the  collection  of  information  for  describing  and  controlling 
the  schedule.  The  schedule  data  includes  at  least  the  schedule  milestones,  schedule  activities,  activity  attributes, 
and  documentation  of  all  identified  assumptions  and  constraints.  The  amount  of  additional  data  varies  by  application 
area.  Information  frequently  supplied  as  supporting  detail  includes,  but  is  not  limited  to: 

• Resource  requirements  by  time  period,  often  in  the  form  of  a resource  histogram; 

• Alternative  schedules,  such  as  best-case  or  worst-case,  not  resource-leveled,  or  resource-leveled,  with 
or  without  imposed  dates;  and 

• Scheduling  of  contingency  reserves. 

Schedule  data  could  also  include  such  items  as  resource  histograms,  cash-flow  projections,  and  order  and 
delivery  schedules. 

6.6.3.4  Project  Calendars 

A project  calendar  identifies  working  days  and  shifts  that  are  available  for  scheduled  activities.  It  distinguishes 
time  periods  in  days  or  parts  of  days  that  are  available  to  complete  scheduled  activities  from  time  periods  that 
are  not  available.  A schedule  model  may  require  more  than  one  project  calendar  to  allow  for  different  work 
periods  for  some  activities  to  calculate  the  project  schedule.  The  project  calendars  may  be  updated. 

6.6.3.5  Project  Management  Plan  Updates 

Elements  of  the  project  management  plan  that  may  be  updated  include,  but  are  not  limited  to: 

• Schedule  baseline  (Section  6.6. 3.1), 

• Schedule  management  plan  (Section  6.1 .3.1 ). 
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6.6.3.6  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Activity  resource  requirements.  Resource  leveling  can  have  a significant  effect  on  preliminary  estimates 
for  the  types  and  quantities  of  resources  required.  If  the  resource-leveling  analysis  changes  the  project 
resource  requirements,  then  the  project  resource  requirements  are  updated. 

• Activity  attributes.  Activity  attributes  (Section  6. 2.3. 2)  are  updated  to  include  any  revised  resource 
requirements  and  any  other  revisions  generated  by  the  Develop  Schedule  process. 

• Calendars.  The  calendar  for  each  project  may  consist  of  multiple  calendars,  project  calendars,  individual 
resource  calendars  etc.,  as  the  basis  for  scheduling  the  project. 

• Risk  register.  The  risk  register  may  need  to  be  updated  to  reflect  opportunities  or  threats  perceived 
through  scheduling  assumptions. 

6.7  Control  Schedule 

Control  Schedule  is  the  process  of  monitoring  the  status  of  project  activities  to  update  project  progress  and 
manage  changes  to  the  schedule  baseline  to  achieve  the  plan.  The  key  benefit  of  this  process  is  that  it  provides 
the  means  to  recognize  deviation  from  the  plan  and  take  corrective  and  preventive  actions  and  thus  minimize 
risk.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  6-22.  Figure  6-23 
depicts  the  data  flow  diagram  of  the  process. 
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Figure  6-22.  Control  Schedule:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  6-23.  Control  Schedule  Data  Flow  Diagram 


Updating  the  schedule  model  requires  knowing  the  actual  performance  to  date.  Any  change  to  the  schedule 
baseline  can  only  be  approved  through  the  Perform  Integrated  Change  Control  process  (Section  4.5).  Control 
Schedule,  as  a component  of  the  Perform  Integrated  Change  Control  process,  is  concerned  with: 

• Determining  the  current  status  of  the  project  schedule, 

• Influencing  the  factors  that  create  schedule  changes, 

• Determining  if  the  project  schedule  has  changed,  and 

• Managing  the  actual  changes  as  they  occur. 
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If  any  agile  approach  is  utilized,  control  schedule  is  concerned  with: 

• Determining  the  current  status  of  the  project  schedule  by  comparing  the  total  amount  of  work  delivered 
and  accepted  against  the  estimates  of  work  completed  for  the  elapsed  time  cycle, 

• Conducting  retrospective  reviews  (scheduled  reviews  to  record  lessons  learned)  for  correcting  processes 
and  improving,  if  required, 

• Reprioritizing  the  remaining  work  plan  (backlog), 

• Determining  the  rate  at  which  the  deliverables  are  produced,  validated,  and  accepted  (velocity)  in  given 
time  per  iteration  (agreed  work  cycle  duration,  typically  two  weeks  or  one  month), 

• Determining  that  the  project  schedule  has  changed,  and 

• Managing  the  actual  changes  as  they  occur. 

6.7.1  Control  Schedule:  Inputs 

6.7.1 .1  Project  Management  Plan 

Described  in  Section  4.2. 3.1.  The  project  management  plan  contains  the  schedule  management  plan  and  the 
schedule  baseline.  The  schedule  management  plan  describes  how  the  schedule  will  be  managed  and  controlled. 
The  schedule  baseline  is  used  as  a reference  to  compare  with  actual  results  to  determine  if  a change,  corrective 
action,  or  preventive  action  is  necessary. 

6.7.1 .2  Project  Schedule 

Described  in  Section  6. 6.3. 2.  Project  schedule  refers  to  the  most  recent  version  with  notations  to  indicate 
updates,  completed  activities,  and  started  activities  as  of  the  indicated  data  date. 

6.7.1 .3  Work  Performance  Data 

Described  in  Section  4.3. 3.2.  Work  performance  data  refers  to  information  about  project  progress  such  as  which 
activities  have  started,  their  progress  (e.g.,  actual  duration,  remaining  duration,  and  physical  percent  complete), 
and  which  activities  have  finished. 
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6.7.1 .4  Project  Calendars 

Described  in  Section  6. 6.3. 4.  A schedule  model  may  require  more  than  one  project  calendar  to  allow  for 
different  work  periods  for  some  activities  to  calculate  the  schedule  forecasts. 

6.7.1 .5  Schedule  Data 

Described  in  Section  6.6. 3.3.  Schedule  data  will  be  reviewed  and  updated  in  the  Control  Schedule  process. 

6.7.1 .6  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  influence  the  Control  Schedule  process 
include,  but  are  not  limited  to: 

• Existing  formal  and  informal  schedule  control-related  policies,  procedures,  and  guidelines; 

• Schedule  control  tools;  and 

• Monitoring  and  reporting  methods  to  be  used. 

6.7.2  Control  Schedule:  Tools  and  Techniques 

6.7.2.1  Performance  Reviews 

Performance  reviews  measure,  compare,  and  analyze  schedule  performance  such  as  actual  start  and 
finish  dates,  percent  complete,  and  remaining  duration  for  work  in  progress.  Various  techniques  may  be  used, 
among  them: 

• Trend  analysis.  Trend  analysis  examines  project  performance  over  time  to  determine  whether 
performance  is  improving  or  deteriorating.  Graphical  analysis  techniques  are  valuable  for  understanding 
performance  to  date  and  for  comparison  to  future  performance  goals  in  the  form  of  completion  dates. 

• Critical  path  method  (Section  6.6.2.2).  Comparing  the  progress  along  the  critical  path  can  help 
determine  schedule  status.  The  variance  on  the  critical  path  will  have  a direct  impact  on  the  project  end 
date.  Evaluating  the  progress  of  activities  on  near  critical  paths  can  identify  schedule  risk. 


1 88  ©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  ( PMBOK ® Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


6 - PROJECT  TIME  MANAGEMENT 


• Critical  chain  method  (Section  6.6.2.3).  Comparing  the  amount  of  buffer  remaining  to  the  amount  of 
buffer  needed  to  protect  the  delivery  date  can  help  determine  schedule  status.  The  difference  between 
the  buffer  needed  and  the  buffer  remaining  can  determine  whether  corrective  action  is  appropriate. 

• Earned  value  management  (Section  7.4.2.1).  Schedule  performance  measurements  such  as  schedule 
variance  (SV)  and  schedule  performance  index  (SPI),  are  used  to  assess  the  magnitude  of  variation  to  the 
original  schedule  baseline. The  total  float  and  early  finish  variances  are  also  essential  planning  components 
to  evaluate  project  time  performance.  Important  aspects  of  schedule  control  include  determining  the  cause 
and  degree  of  variance  relative  to  the  schedule  baseline  (Section  6.6. 3.1),  estimating  the  implications 
of  those  variances  for  future  work  to  completion,  and  deciding  whether  corrective  or  preventive  action 
is  required.  For  example,  a major  delay  on  any  activity  not  on  the  critical  path  may  have  little  effect  on 
the  overall  project  schedule,  while  a much  shorter  delay  on  a critical  or  near-critical  activity  may  require 
immediate  action.  For  projects  not  using  earned  value  management,  similar  variance  analysis  can  be 
performed  by  comparing  planned  activity  start  or  finish  dates  against  actual  start  or  finish  dates  to 
identify  variances  between  the  schedule  baseline  and  actual  project  performance.  Further  analysis  can 
be  performed  to  determine  the  cause  and  degree  of  variance  relative  to  the  schedule  baseline  and  any 
corrective  or  preventative  actions  needed. 

6.7.2.2  Project  Management  Software 

Project  management  software  for  scheduling  provides  the  ability  to  track  planned  dates  versus  actual  dates, 
to  report  variances  to  and  progress  made  against  the  schedule  baseline,  and  to  forecast  the  effects  of  changes 
to  the  project  schedule  model. 

6.7.2.3  Resource  Optimization  Techniques 

Described  in  Section  6. 6.2. 4.  Resource  optimization  techniques  involve  the  scheduling  of  activities  and  the 
resources  required  by  those  activities  while  taking  into  consideration  both  the  resource  availability  and  the  project 
time. 

6.7.2.4  Modeling  Techniques 

Described  in  Section  6.6. 2.5.  Modeling  techniques  are  used  to  review  various  scenarios  guided  by  risk  monitoring 
to  bring  the  schedule  model  into  alignment  with  the  project  management  plan  and  approved  baseline. 
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67.2.5  Leads  and  Lags 

Adjusting  leads  and  lags  is  applied  during  network  analysis  to  find  ways  to  bring  project  activities  that  are 
behind  into  alignment  with  the  plan.  For  example,  on  a project  to  construct  a new  office  building,  the  landscaping 
can  be  adjusted  to  start  before  the  exterior  work  of  the  building  is  complete  by  increasing  the  lead  time  in  the 
relationship.  Or,  a technical  writing  team  can  adjust  the  start  of  editing  the  draft  of  a large  document  immediately 
after  the  document  is  completed  by  eliminating  or  decreasing  lag  time. 

67.2.6  Schedule  Compression 

Described  in  Section  6.6.27.  Schedule  compression  techniques  are  used  to  find  ways  to  bring  project  activities 
that  are  behind  into  alignment  with  the  plan  by  fast  tracking  or  crashing  schedule  for  the  remaining  work. 

6.7.27  Scheduling  Tool 

Schedule  data  is  updated  and  compiled  into  the  schedule  model  to  reflect  actual  progress  of  the  project  and 
remaining  work  to  be  completed.  The  scheduling  tool  (Section  6. 6.2. 8)  and  the  supporting  schedule  data  are  used 
in  conjunction  with  manual  methods  or  other  project  management  software  to  perform  schedule  network  analysis 
to  generate  an  updated  project  schedule. 

6.7.3  Control  Schedule:  Outputs 

67.3.1  Work  Performance  Information 

The  calculated  S V and  SPI  time  performance  indicators  for  WBS  components,  in  particular  the  work  packages 
and  control  accounts,  are  documented  and  communicated  to  stakeholders. 

67.3.2  Schedule  Forecasts 

Schedule  forecasts  are  estimates  or  predictions  of  conditions  and  events  in  the  project’s  future  based  on 
information  and  knowledge  available  at  the  time  of  the  forecast.  Forecasts  are  updated  and  reissued  based  on 
work  performance  information  provided  as  the  project  is  executed.  The  information  is  based  on  the  project’s  past 
performance  and  expected  future  performance,  and  includes  earned  value  performance  indicators  that  could 
impact  the  project  in  the  future. 
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6.7.3.3  Change  Requests 

Schedule  variance  analysis,  along  with  review  of  progress  reports,  results  of  performance  measures,  and 
modifications  to  the  project  scope  or  project  schedule  may  result  in  change  requests  to  the  schedule  baseline, 
scope  baseline,  and/or  other  components  of  the  project  management  plan.  Change  requests  are  processed  for 
review  and  disposition  through  the  Perform  Integrated  Change  Control  process  (Section  4.5).  Preventive  actions 
may  include  recommended  changes  to  eliminate  or  reduce  the  probability  of  negative  schedule  variances. 

6.7.3.4  Project  Management  Plan  Updates 

Elements  of  the  project  management  plan  that  may  be  updated  include,  but  are  not  limited  to: 

• Schedule  baseline.  Changes  to  the  schedule  baseline  are  incorporated  in  response  to  approved  change 
requests  (Section  4. 4.3.1)  related  to  project  scope  changes,  activity  resources,  or  activity  duration 
estimates.  The  schedule  baseline  may  be  updated  to  reflect  changes  caused  by  schedule  compression 
techniques. 

• Schedule  management  plan.  The  schedule  management  plan  may  be  updated  to  reflect  a change  in 
the  way  the  schedule  is  managed. 

• Cost  baseline.  The  cost  baseline  may  be  updated  to  reflect  approved  change  requests  or  changes  caused 
by  compression  techniques. 

6.7.3.5  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Schedule  Data.  New  project  schedule  network  diagrams  may  be  developed  to  display  approved  remaining 
durations  and  approved  modifications  to  the  schedule.  In  some  cases,  project  schedule  delays  can  be 
so  severe  that  development  of  a new  target  schedule  with  forecasted  start  and  finish  dates  is  needed  to 
provide  realistic  data  for  directing  the  work,  measuring  performance,  and  measuring  progress. 

• Project  Schedule.  An  updated  project  schedule  will  be  generated  from  the  schedule  model  populated 
with  updated  schedule  data  to  reflect  the  schedule  changes  and  manage  the  project. 

• Risk  Register.  The  risk  register,  and  risk  response  plans  within  it,  may  also  be  updated  based  on  the  risks 
that  may  arise  due  to  schedule  compression  techniques. 
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67.3.6  Organizational  Process  Assets  Updates 

Organizational  process  assets  that  may  be  updated  include,  but  are  not  limited  to: 

• Causes  of  variances, 

• Corrective  action  chosen  and  the  reasons,  and 

• Other  types  of  lessons  learned  from  project  schedule  control. 
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PROJECT  COST  MANAGEMENT 


Project  Cost  Management  includes  the  processes  involved  in  planning,  estimating,  budgeting,  financing,  funding, 
managing,  and  controlling  costs  so  that  the  project  can  be  completed  within  the  approved  budget. 

Figure  7-1  provides  an  overview  of  the  following  Project  Cost  Management  processes: 

7.1  Plan  Cost  Management — The  process  that  establishes  the  policies,  procedures,  and  documentation 
for  planning,  managing,  expending,  and  controlling  project  costs. 

7.2  Estimate  Costs — The  process  of  developing  an  approximation  of  the  monetary  resources  needed  to 
complete  project  activities. 

7.3  Determine  Budget — The  process  of  aggregating  the  estimated  costs  of  individual  activities  or  work 
packages  to  establish  an  authorized  cost  baseline. 

7.4  Control  Costs — The  process  of  monitoring  the  status  of  the  project  to  update  the  project  costs  and 
managing  changes  to  the  cost  baseline. 

These  processes  interact  with  each  other  and  with  processes  in  other  Knowledge  Areas  as  described  in 
detail  in  Section  3 and  Annex  A1 . 

On  some  projects,  especially  those  of  smaller  scope,  cost  estimating  and  cost  budgeting  are  tightly  linked 
and  can  be  viewed  as  a single  process  that  can  be  performed  by  a single  person  over  a relatively  short  period 
of  time.  These  are  presented  here  as  distinct  processes  because  the  tools  and  techniques  for  each  are  different. 
The  ability  to  influence  cost  is  greatest  at  the  early  stages  of  the  project,  making  early  scope  definition  critical 
(Section  5.3). 
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Figure  7-1 . Project  Cost  Management  Overview 
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Project  Cost  Management  should  consider  the  stakeholder  requirements  for  managing  costs.  Different 
stakeholders  will  measure  project  costs  in  different  ways  and  at  different  times.  For  example,  the  cost  of  an 
acquired  item  may  be  measured  when  the  acquisition  decision  is  made  or  committed,  the  order  is  placed,  the  item 
is  delivered,  or  the  actual  cost  is  incurred  or  recorded  for  project  accounting  purposes. 

Project  Cost  Management  is  primarily  concerned  with  the  cost  of  the  resources  needed  to  complete  project 
activities.  Project  Cost  Management  should  also  consider  the  effect  of  project  decisions  on  the  subsequent  recurring 
cost  of  using,  maintaining,  and  supporting  the  product,  service,  or  result  of  the  project.  For  example,  limiting  the 
number  of  design  reviews  can  reduce  the  cost  of  the  project  but  could  increase  the  resulting  product’s  operating 
costs. 

In  many  organizations,  predicting  and  analyzing  the  prospective  financial  performance  of  the  project’s  product  is 
performed  outside  of  the  project.  In  others,  such  as  a capital  facilities  project,  Project  Cost  Management  can  include 
this  work.  When  such  predictions  and  analyses  are  included,  Project  Cost  Management  may  address  additional 
processes  and  numerous  general  financial  management  techniques  such  as  return  on  investment,  discounted  cash 
flow,  and  investment  payback  analysis. 

The  cost  management  planning  effort  occurs  early  in  project  planning  and  sets  the  framework  for  each  of  the 
cost  management  processes  so  that  performance  of  the  processes  will  be  efficient  and  coordinated. 


7.1  Plan  Cost  Management 

Plan  Cost  Management  is  the  process  that  establishes  the  policies,  procedures,  and  documentation  for  planning, 
managing,  expending,  and  controlling  project  costs.  The  key  benefit  of  this  process  is  that  it  provides  guidance  and 
direction  on  how  the  project  costs  will  be  managed  throughout  the  project.  The  inputs,  tools  and  techniques,  and 
outputs  of  this  process  are  depicted  in  Figure  7-2.  Figure  7-3  depicts  the  data  flow  diagram  of  the  process. 
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Figure  7-2.  Plan  Cost  Management:  Inputs,  Tools  & Techniques,  and  Outputs 
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7.1.1  Plan  Cost  Management:  Inputs 

7.1 .1 .1  Project  Management  Plan 

Described  in  Section  4.2. 3.1 . The  project  management  plan  contains  information  used  to  develop  the  cost 
management  plan,  which  contains,  but  is  not  limited  to: 

• Scope  baseline.  The  scope  baseline  includes  the  project  scope  statement  and  WBS  detail  for  cost 
estimation  and  management. 

• Schedule  baseline.  The  schedule  baseline  defines  when  the  project  costs  will  be  incurred. 

• Other  information.  Other  cost-related  scheduling,  risk,  and  communications  decisions  from  the  project 
management  plan. 
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7.1 .1 .2  Project  Charter 

Described  in  Section  4.1 .3.1 . The  project  charter  provides  the  summary  budget  from  which  the  detailed  project 
costs  are  developed.  The  project  charter  also  defines  the  project  approval  requirements  that  will  influence  the 
management  of  the  project  costs. 

7.1 .1.3  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  The  enterprise  environmental  factors  that  influence  the  Plan  Cost  Management 
process  include,  but  are  not  limited  to: 

• Organizational  culture  and  structure  can  all  influence  cost  management;  7 

• Market  conditions  describe  what  products,  services,  and  results  are  available  in  the  regional  and  global 
market; 

• Currency  exchange  rates  for  project  costs  sourced  from  more  than  one  country; 

• Published  commercial  information  such  as  resource  cost  rate  information  is  often  available  from 
commercial  databases  that  track  skills  and  human  resource  costs,  and  provide  standard  costs  for  material 
and  equipment.  Published  seller  price  lists  are  another  source  of  information;  and 

• Project  management  information  system,  which  provides  alternative  possibilities  for  managing  cost. 

7.1 .1 .4  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  influence  the  Plan  Cost  Management  process 
include,  but  are  not  limited  to: 

• Financial  controls  procedures  (e.g.,  time  reporting,  required  expenditure  and  disbursement  reviews, 
accounting  codes,  and  standard  contract  provisions); 

• Historical  information  and  lessons  learned  knowledge  bases; 

• Financial  databases;  and 

• Existing  formal  and  informal  cost  estimating  and  budgeting-related  policies,  procedures,  and  guidelines. 
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7.1.2  Plan  Cost  Management:  Tools  and  Techniques 

7.1 .2.1  Expert  Judgment 

Expert  judgment,  guided  by  historical  information,  provides  valuable  insight  about  the  environment  and 
information  from  prior  similar  projects.  Expert  judgment  can  also  suggest  whether  to  combine  methods  and  how  to 
reconcile  differences  between  them. 

Judgment  based  upon  expertise  in  an  application  area,  Knowledge  Area,  discipline,  industry,  etc.,  as  appropriate 
for  the  activity  being  performed  should  be  used  in  developing  the  cost  management  plan. 

7.1 .2.2  Analytical  Techniques 

Developing  the  cost  management  plan  may  involve  choosing  strategic  options  to  fund  the  project  such  as: 
self-funding,  funding  with  equity,  or  funding  with  debt.  The  cost  management  plan  may  also  detail  ways  to  finance 
project  resources  such  as  making,  purchasing,  renting,  or  leasing.  These  decisions,  like  other  financial  decisions 
affecting  the  project,  may  affect  project  schedule  and/or  risks. 

Organizational  policies  and  procedures  may  influence  which  financial  techniques  are  employed  in  these 
decisions.  Techniques  may  include  (but  are  not  limited  to):  payback  period,  return  on  investment,  internal  rate  of 
return,  discounted  cash  flow,  and  net  present  value. 

7.1 .2.3  Meetings 

Project  teams  may  hold  planning  meetings  to  develop  the  cost  management  plan.  Attendees  at  these  meetings 
may  include  the  project  manager,  the  project  sponsor,  selected  project  team  members,  selected  stakeholders, 
anyone  with  responsibility  for  project  costs,  and  others  as  needed. 

7.1.3  Plan  Cost  Management:  Outputs 
7.1 .3.1  Cost  Management  Plan 

The  cost  management  plan  is  a component  of  the  project  management  plan  and  describes  how  the  project 
costs  will  be  planned,  structured,  and  controlled.  The  cost  management  processes  and  their  associated  tools  and 
techniques  are  documented  in  the  cost  management  plan. 
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For  example,  the  cost  management  plan  can  establish  the  following: 

• Units  of  measure.  Each  unit  used  in  measurements  (such  as  staff  hours,  staff  days,  weeks  for  time 
measures;  or  meters,  liters,  tons,  kilometers,  or  cubic  yards  for  quantity  measures;  or  lump  sum  in 
currency  form)  is  defined  for  each  of  the  resources. 

• Level  of  precision.  The  degree  to  which  activity  cost  estimates  will  be  rounded  up  or  down  (e.g., 
US$1 00.49  to  US$1 00,  or  US$995.59  to  US$1 ,000),  based  on  the  scope  of  the  activities  and  magnitude 
of  the  project. 

• Level  of  accuracy.  The  acceptable  range  (e.g.,  ±1 0%)  used  in  determining  realistic  activity  cost  estimates 
is  specified,  and  may  include  an  amount  for  contingencies; 

• Organizational  procedures  links.  The  work  breakdown  structure  (WBS)  (Section  5.4)  provides  the 
framework  for  the  cost  management  plan,  allowing  for  consistency  with  the  estimates,  budgets,  and 
control  of  costs.  The  WBS  component  used  for  the  project  cost  accounting  is  called  the  control  account. 
Each  control  account  is  assigned  a unique  code  or  account  number(s)  that  links  directly  to  the  performing 
organization’s  accounting  system. 

• Control  thresholds.  Variance  thresholds  for  monitoring  cost  performance  may  be  specified  to  indicate 
an  agreed-upon  amount  of  variation  to  be  allowed  before  some  action  needs  to  be  taken.  Thresholds  are 
typically  expressed  as  percentage  deviations  from  the  baseline  plan. 

• Rules  of  performance  measurement.  Earned  value  management  (EVM)  rules  of  performance 
measurement  are  set.  For  example,  the  cost  management  plan  may: 

o Define  the  points  in  the  WBS  at  which  measurement  of  control  accounts  will  be  performed; 

o Establish  the  earned  value  measurement  techniques  (e.g.,  weighted  milestones,  fixed-formula, 
percent  complete,  etc.)  to  be  employed;  and 

o Specify  tracking  methodologies  and  the  earned  value  management  computation  equations  for 
calculating  projected  estimate  at  completion  (EAC)  forecasts  to  provide  a validity  check  on  the 
bottom-up  EAC. 

For  more  specific  information  regarding  earned  value  management,  refer  to  the  Practice  Standard  for 
Earned  Value  Management  - Second  Edition. 
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• Reporting  formats.  The  formats  and  frequency  for  the  various  cost  reports  are  defined. 

• Process  descriptions.  Descriptions  of  each  of  the  other  cost  management  processes  are  documented. 

• Additional  details.  Additional  details  about  cost  management  activities  include,  but  are  not  limited  to: 

o Description  of  strategic  funding  choices, 
o Procedure  to  account  for  fluctuations  in  currency  exchange  rates,  and 
o Procedure  for  project  cost  recording. 


7.2  Estimate  Costs 

Estimate  Costs  is  the  process  of  developing  an  approximation  of  the  monetary  resources  needed  to  complete 
project  activities.  The  key  benefit  of  this  process  is  that  it  determines  the  amount  of  cost  required  to  complete 
project  work.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  7-4.  Figure  7-5 
depicts  the  data  flow  diagram  of  the  process. 
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Figure  7-4.  Estimate  Costs:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  7-5.  Estimate  Costs  Data  Flow  Diagram 


Cost  estimates  are  a prediction  that  is  based  on  the  information  known  at  a given  point  in  time.  Cost  estimates 
include  the  identification  and  consideration  of  costing  alternatives  to  initiate  and  complete  the  project.  Cost  trade- 
offs and  risks  should  be  considered,  such  as  make  versus  buy,  buy  versus  lease,  and  the  sharing  of  resources  in 
order  to  achieve  optimal  costs  for  the  project. 


Cost  estimates  are  generally  expressed  in  units  of  some  currency  (i.e.,  dollars,  euros,  yen,  etc.),  although  in 
some  instances  other  units  of  measure,  such  as  staff  hours  or  staff  days,  are  used  to  facilitate  comparisons  by 
eliminating  the  effects  of  currency  fluctuations. 

Cost  estimates  should  be  reviewed  and  refined  during  the  course  of  the  project  to  reflect  additional  detail 
as  it  becomes  available  and  assumptions  are  tested.  The  accuracy  of  a project  estimate  will  increase  as  the 
project  progresses  through  the  project  life  cycle.  For  example,  a project  in  the  initiation  phase  may  have  a rough 
order  of  magnitude  (ROM)  estimate  in  the  range  of  -25%  to  +75%.  Later  in  the  project,  as  more  information  is 
known,  definitive  estimates  could  narrow  the  range  of  accuracy  to  -5%  to  +10%.  In  some  organizations,  there  are 
guidelines  for  when  such  refinements  can  be  made  and  the  degree  of  confidence  or  accuracy  that  is  expected. 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK®  Guide)  - Fifth  Edition 


201 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


7 - PROJECT  COST  MANAGEMENT 


Sources  of  input  information  are  derived  from  the  outputs  of  processes  in  other  Knowledge  Areas.  Once  received, 
all  of  this  information  will  remain  available  as  inputs  to  all  of  the  cost  management  processes. 

Costs  are  estimated  for  all  resources  that  will  be  charged  to  the  project.  This  includes,  but  is  not  limited  to,  labor, 
materials,  equipment,  services,  and  facilities,  as  well  as  special  categories  such  as  an  inflation  allowance,  cost 
of  financing,  or  contingency  costs.  A cost  estimate  is  a quantitative  assessment  of  the  likely  costs  for  resources 
required  to  complete  the  activity.  Cost  estimates  may  be  presented  at  the  activity  level  or  in  summary  form. 

7.2.1  Estimate  Costs:  Inputs 

7.2.1 .1  Cost  Management  Plan 

Described  in  Section  7. 1.3.1.  The  cost  management  plan  defines  how  project  costs  will  be  managed  and 
controlled.  It  includes  the  method  used  and  the  level  of  accuracy  required  to  estimate  activity  cost. 

7.2.1 .2  Human  Resource  Management  Plan 

Described  in  Section  9. 1.3.1.  The  human  resource  management  plan  provides  project  staffing  attributes, 
personnel  rates,  and  related  rewards/recognition,  which  are  necessary  components  for  developing  the  project  cost 
estimates. 

7.2.1 .3  Scope  Baseline 

The  scope  baseline  is  comprised  of  the  following: 

• Project  scope  statement.  The  project  scope  statement  (Section  5.3. 3.1)  provides  the  product  description, 
acceptance  criteria,  key  deliverables,  project  boundaries,  assumptions,  and  constraints  about  the  project. 
One  basic  assumption  that  needs  to  be  made  when  estimating  project  costs  is  whether  the  estimates  will 
be  limited  to  direct  project  costs  only  or  whether  the  estimates  will  also  include  indirect  costs.  Indirect 
costs  are  those  costs  that  cannot  be  directly  traced  to  a specific  project  and  therefore  will  be  accumulated 
and  allocated  equitably  over  multiple  projects  by  some  approved  and  documented  accounting  procedure. 
One  of  the  most  common  constraints  for  many  projects  is  a limited  project  budget.  Examples  of  other 
constraints  are  required  delivery  dates,  available  skilled  resources,  and  organizational  policies. 

• Work  breakdown  structure.  The  WBS  (Section  5.4)  provides  the  relationships  among  all  the  components 
of  the  project  and  the  project  deliverables. 

• WBS  dictionary.  The  WBS  dictionary  (Section  5. 4.3.1)  provides  detailed  information  about  the  deliverables 
and  a description  of  the  work  for  each  component  in  the  WBS  required  to  produce  each  deliverable. 
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Additional  information  that  may  be  found  in  the  scope  baseline  with  contractual  and  legal  implications,  such  as 
health,  safety,  security,  performance,  environmental,  insurance,  intellectual  property  rights,  licenses,  and  permits. 
All  of  this  information  should  be  considered  when  developing  the  cost  estimates. 

7.2.1 .4  Project  Schedule 

Described  in  Section  6. 6.3. 2.  The  type  and  quantity  of  resources  and  the  amount  of  time  which  those  resources 
are  applied  to  complete  the  work  of  the  project  are  major  factors  in  determining  the  project  cost.  Schedule  activity 
resources  and  their  respective  durations  are  used  as  key  inputs  to  this  process.  Estimate  Activity  Resources  (Section 
6.4)  involves  determining  the  availability  of  staff,  the  number  of  staff  hours  required,  and  quantities  of  material  and 
equipment  needed  to  perform  schedule  activities.  It  is  closely  coordinated  with  cost  estimating.  Activity  duration 
estimates  (Section  6. 5.3.1 ) will  affect  cost  estimates  on  any  project  where  the  project  budget  includes  an  allowance 
for  the  cost  of  financing  (including  interest  charges)  and  where  resources  are  applied  per  unit  of  time  for  the 
duration  of  the  activity.  Activity  duration  estimates  can  also  affect  cost  estimates  that  have  time-sensitive  costs 
included  in  them,  such  as  union  labor  with  regularly  expiring  collective  bargaining  agreements  or  materials  with 
seasonal  cost  variations. 

7.2.1 .5  Risk  Register 

Described  in  Section  11.2.3.1.  The  risk  register  should  be  reviewed  to  consider  risk  response  costs.  Risks, 
which  can  be  either  threats  or  opportunities,  typically  have  an  impact  on  both  activity  and  overall  project  costs.  As 
a general  rule,  when  the  project  experiences  a negative  risk  event,  the  near-term  cost  of  the  project  will  usually 
increase,  and  there  will  sometimes  be  a delay  in  the  project  schedule.  In  a similar  way,  the  project  team  should 
be  sensitive  to  potential  opportunities  that  can  benefit  the  business  either  by  directly  reducing  activity  costs  or  by 
accelerating  the  schedule. 

7.2.1 .6  Enterprise  Environmental  Factors 

Described  in  Section  2.1.5.  The  enterprise  environmental  factors  that  influence  the  Estimate  Costs  process 
include,  but  are  not  limited  to: 

• Market  conditions.  These  conditions  describe  what  products,  services,  and  results  are  available  in  the 
market,  from  whom,  and  under  what  terms  and  conditions.  Regional  and/or  global  supply  and  demand 
conditions  greatly  influence  resource  costs. 
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• Published  commercial  information.  Resource  cost  rate  information  is  often  available  from  commercial 
databases  that  track  skills  and  human  resource  costs,  and  provide  standard  costs  for  material  and 
equipment.  Published  seller  price  lists  are  another  source  of  information. 

7.2.1 .7  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  influence  the  Estimate  Costs  process  include, 
but  are  not  limited  to: 

• Cost  estimating  policies, 

• Cost  estimating  templates, 

• Historical  information,  and 

• Lessons  learned. 

7.2.2  Estimate  Costs:  Tools  and  Techniques 

7.2.2.1  Expert  Judgment 

Expert  judgment,  guided  by  historical  information,  provides  valuable  insight  about  the  environment  and 
information  from  prior  similar  projects.  Expert  judgment  can  also  be  used  to  determine  whether  to  combine  methods 
of  estimating  and  how  to  reconcile  differences  between  them. 

7.2.2.2  Analogous  Estimating 

Analogous  cost  estimating  uses  the  values  such  as  scope,  cost,  budget,  and  duration  or  measures  of  scale  such 
as  size,  weight,  and  complexity  from  a previous,  similar  project  as  the  basis  for  estimating  the  same  parameter 
or  measurement  for  a current  project.  When  estimating  costs,  this  technique  relies  on  the  actual  cost  of  previous, 
similar  projects  as  the  basis  for  estimating  the  cost  of  the  current  project.  It  is  a gross  value  estimating  approach, 
sometimes  adjusted  for  known  differences  in  project  complexity. 

Analogous  cost  estimating  is  frequently  used  to  estimate  a value  when  there  is  a limited  amount  of  detailed 
information  about  the  project,  for  example,  in  the  early  phases  of  a project.  Analogous  cost  estimating  uses 
historical  information  and  expert  judgment. 
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Analogous  cost  estimating  is  generally  less  costly  and  less  time  consuming  than  other  techniques,  but  it  is  also 
generally  less  accurate.  Analogous  cost  estimates  can  be  applied  to  a total  project  or  to  segments  of  a project,  in 
conjunction  with  other  estimating  methods.  Analogous  estimating  is  most  reliable  when  the  previous  projects  are 
similar  in  fact  and  not  just  in  appearance,  and  the  project  team  members  preparing  the  estimates  have  the  needed 
expertise. 

7.2.2.3  Parametric  Estimating 

Parametric  estimating  uses  a statistical  relationship  between  relevant  historical  data  and  other  variables  (e.g., 
square  footage  in  construction)  to  calculate  a cost  estimate  for  project  work.  This  technique  can  produce  higher 
levels  of  accuracy  depending  upon  the  sophistication  and  underlying  data  built  into  the  model.  Parametric  cost 
estimates  can  be  applied  to  a total  project  or  to  segments  of  a project,  in  conjunction  with  other  estimating  methods. 

7.2.2.4  Bottom-Up  Estimating 

Bottom-up  estimating  is  a method  of  estimating  a component  of  work.  The  cost  of  individual  work  packages  or 
activities  is  estimated  to  the  greatest  level  of  specified  detail.  The  detailed  cost  is  then  summarized  or  “rolled  up”  to 
higher  levels  for  subsequent  reporting  and  tracking  purposes.  The  cost  and  accuracy  of  bottom-up  cost  estimating 
are  typically  influenced  by  the  size  and  complexity  of  the  individual  activity  or  work  package. 

7.2.2.5  Three-Point  Estimating 

The  accuracy  of  single-point  activity  cost  estimates  may  be  improved  by  considering  estimation  uncertainty  and 
risk  and  using  three  estimates  to  define  an  approximate  range  for  an  activity’s  cost: 

• Most  likely  (cM).  The  cost  of  the  activity,  based  on  realistic  effort  assessment  for  the  required  work  and 
any  predicted  expenses. 

• Optimistic  (cO).  The  activity  cost  based  on  analysis  of  the  best-case  scenario  for  the  activity. 

• Pessimistic  (cF).  The  activity  cost  based  on  analysis  of  the  worst-case  scenario  for  the  activity. 
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Depending  on  the  assumed  distribution  of  values  within  the  range  of  the  three  estimates  the  expected  cost,  cE, 
can  be  calculated  using  a formula.  Two  commonly  used  formulas  are  triangular  and  beta  distributions.  The  formulas 
are: 


• Triangular  Distribution.  cE  = (cO  + cM  + cP)  / 3 

• Beta  Distribution  (from  a traditional  PERT  analysis).  cE  = (cO  + 4cM  + cP)  / 6 

Cost  estimates  based  on  three  points  with  an  assumed  distribution  provide  an  expected  cost  and  clarify  the 
range  of  uncertainty  around  the  expected  cost. 

7.2.2.6  Reserve  Analysis 

Cost  estimates  may  include  contingency  reserves  (sometimes  called  contingency  allowances)  to  account  for 
cost  uncertainty.  Contingency  reserves  are  the  budget  within  the  cost  baseline  that  is  allocated  for  identified  risks, 
which  are  accepted  and  for  which  contingent  or  mitigating  responses  are  developed.  Contingency  reserves  are 
often  viewed  as  the  part  of  the  budget  intended  to  address  the  “known-unknowns”  that  can  affect  a project.  For 
example,  rework  for  some  project  deliverables  could  be  anticipated,  while  the  amount  of  this  rework  is  unknown. 
Contingency  reserves  may  be  estimated  to  account  for  this  unknown  amount  of  rework.  Contingency  reserves  can 
provide  for  a specific  activity,  for  the  whole  project,  or  both.  The  contingency  reserve  may  be  a percentage  of  the 
estimated  cost,  a fixed  number,  or  may  be  developed  by  using  quantitative  analysis  methods. 

As  more  precise  information  about  the  project  becomes  available,  the  contingency  reserve  may  be  used, 
reduced,  or  eliminated.  Contingency  should  be  clearly  identified  in  cost  documentation.  Contingency  reserves  are 
part  of  the  cost  baseline  and  the  overall  funding  requirements  for  the  project. 

Estimates  may  also  be  produced  for  the  amount  of  management  reserve  to  be  funded  for  the  project. 
Management  reserves  are  an  amount  of  the  project  budget  withheld  for  management  control  purposes  and  are 
reserved  for  unforeseen  work  that  is  within  scope  of  the  project.  Management  reserves  are  intended  to  address  the 
“unknown  unknowns”  that  can  affect  a project.  The  management  reserve  is  not  included  in  the  cost  baseline  but 
is  part  of  the  overall  project  budget  and  funding  requirements.  When  an  amount  of  management  reserves  is  used 
to  fund  unforeseen  work,  the  amount  of  management  reserve  used  is  added  to  the  cost  baseline,  thus  requiring  an 
approved  change  to  the  cost  baseline. 

7.2.27  Cost  of  Quality  (COQ) 

Assumptions  about  costs  of  quality  (Section  8.1 .2.2)  may  be  used  to  prepare  the  activity  cost  estimate. 
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7.2.2.8  Project  Management  Software 

Project  management  software  applications,  computerized  spreadsheets,  simulation,  and  statistical  tools  are 
used  to  assist  with  cost  estimating.  Such  tools  can  simplify  the  use  of  some  cost-estimating  techniques  and  thereby 
facilitate  rapid  consideration  of  cost  estimate  alternatives. 

7.2.2.9  Vendor  Bid  Analysis 

Cost  estimating  methods  may  include  analysis  of  what  the  project  should  cost,  based  on  the  responsive  bids  from 
qualified  vendors.  When  projects  are  awarded  to  a vendor  under  competitive  processes,  additional  cost  estimating 
work  may  be  required  of  the  project  team  to  examine  the  price  of  individual  deliverables  and  to  derive  a cost  that 
supports  the  final  total  project  cost. 

7.2.2.10  Group  Decision-Making  Techniques 

Team-based  approaches,  such  as  brainstorming,  the  Delphi  or  nominal  group  techniques,  are  useful  for  engaging 
team  members  to  improve  estimate  accuracy  and  commitment  to  the  emerging  estimates.  By  involving  a structured 
group  of  people  who  are  close  to  the  technical  execution  of  work  in  the  estimation  process,  additional  information  is 
gained  and  more  accurate  estimates  are  obtained.  Additionally,  when  people  are  involved  in  the  estimation  process, 
their  commitment  towards  meeting  the  resulting  estimates  increases. 

7.2.3  Estimate  Costs:  Outputs 

7.2.3.1  Activity  Cost  Estimates 

Activity  cost  estimates  are  quantitative  assessments  of  the  probable  costs  required  to  complete  project 
work.  Cost  estimates  can  be  presented  in  summary  form  or  in  detail.  Costs  are  estimated  for  all  resources  that 
are  applied  to  the  activity  cost  estimate.  This  includes,  but  is  not  limited  to,  direct  labor,  materials,  equipment, 
services,  facilities,  information  technology,  and  special  categories  such  as  cost  of  financing  (including  interest 
charges),  an  inflation  allowance,  exchange  rates,  or  a cost  contingency  reserve.  Indirect  costs,  if  they  are  included 
in  the  project  estimate,  can  be  included  at  the  activity  level  or  at  higher  levels. 
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7.2.3.2  Basis  of  Estimates 

The  amount  and  type  of  additional  details  supporting  the  cost  estimate  vary  by  application  area.  Regardless  of 
the  level  of  detail,  the  supporting  documentation  should  provide  a clear  and  complete  understanding  of  how  the 
cost  estimate  was  derived. 

Supporting  detail  for  activity  cost  estimates  may  include: 

• Documentation  of  the  basis  of  the  estimate  (i.e.,  how  it  was  developed), 

• Documentation  of  all  assumptions  made, 

• Documentation  of  any  known  constraints, 

• Indication  of  the  range  of  possible  estimates  (e.g.,  €1 0,000  (±1 0%)  to  indicate  that  the  item  is  expected 
to  cost  between  a range  of  values),  and 

• Indication  of  the  confidence  level  of  the  final  estimate. 

7.2.3.3  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to,  the  risk  register. 


7.3  Determine  Budget 

Determine  Budget  is  the  process  of  aggregating  the  estimated  costs  of  individual  activities  or  work  packages  to 
establish  an  authorized  cost  baseline.  The  key  benefit  of  this  process  is  that  it  determines  the  cost  baseline  against 
which  project  performance  can  be  monitored  and  controlled.  The  inputs,  tools  and  techniques,  and  outputs  of  this 
process  are  depicted  in  Figure  7-6.  Figure  7-7  depicts  the  data  flow  diagram  of  the  process. 
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Figure  7-6.  Determine  Budget:  Inputs,  Tools  & Techniques,  and  Outputs 
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A project  budget  includes  all  the  funds  authorized  to  execute  the  project.  The  cost  baseline  is  the  approved 
version  of  the  time-phased  project  budget,  but  excludes  management  reserves. 

7.3.1  Determine  Budget:  Inputs 

7.3.1 .1  Cost  Management  Plan 

Described  in  Section  7.1 .3.1 . The  cost  management  plan  describes  how  the  project  costs  will  be  managed  and 
controlled. 


Project  Cost  Management 


Figure  7-7.  Determine  Budget  Data  Flow  Diagram 
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7.3.1 .2  Scope  Baseline 

• Project  scope  statement.  Formal  limitations  by  period  for  the  expenditure  of  project  funds  can  be 
mandated  by  the  organization,  by  agreement  (Section  12.2.3.2),  or  by  other  entities  such  as  government 
agencies.  These  funding  constraints  are  reflected  in  the  project  scope  statement. 

• Work  breakdown  structure.  The  WBS  (Section  5.4)  provides  the  relationships  among  all  the  project 
deliverables  and  their  various  components. 

• WBS  dictionary.  The  WBS  dictionary  (Section  5. 4.3.1)  and  related  detailed  statements  of  work  provide 
an  identification  of  the  deliverables  and  a description  of  the  work  in  each  WBS  component  required  to 
produce  each  deliverable. 

7.3.1 .3  Activity  Cost  Estimates 

Described  in  Section  7. 2.3.1 . Cost  estimates  for  each  activity  within  a work  package  are  aggregated  to  obtain  a 
cost  estimate  for  each  work  package. 

7.3.1 .4  Basis  of  Estimates 

Described  in  Section  7. 2.3. 2.  Supporting  detail  for  cost  estimates  contained  in  the  basis  for  estimates  should 
specify  any  basic  assumptions  dealing  with  the  inclusion  or  exclusion  of  indirect  or  other  costs  in  the  project  budget. 

7.3.1 .5  Project  Schedule 

Described  in  Section  6. 6.3. 2.  The  project  schedule  includes  planned  start  and  finish  dates  for  the  project’s 
activities,  milestones,  work  packages,  and  control  accounts.  This  information  can  be  used  to  aggregate  costs  to  the 
calendar  periods  in  which  the  costs  are  planned  to  be  incurred. 

7.3.1 .6  Resource  Calendars 

Described  in  Sections  9.2. 3.2  and  12.2.3.3.  Resource  calendars  provide  information  on  which  resources  are 
assigned  to  the  project  and  when  they  are  assigned.  This  information  can  be  used  to  indicate  resource  costs  over 
the  duration  of  the  project. 

7.3.1 .7  Risk  Register 

Described  in  Section  1 1 .2.3.1  .The  risk  register  should  be  reviewed  to  consider  howto  aggregate  the  risk  response 
costs.  Updates  to  the  risk  register  are  included  with  project  document  updates  described  in  Section  1 1 .5.3.2. 
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7.3.1 .8  Agreements 

Described  in  Section  12.2.3.2.  Applicable  agreement  information  and  costs  relating  to  products,  services,  or 
results  that  have  been  or  will  be  purchased  are  included  when  determining  the  budget. 

7.3.1 .9  Organizational  Process  Assets 

Described  in  Section  2.1.4.  The  organizational  process  assets  that  influence  the  Determine  Budget  process 
include,  but  are  not  limited  to: 

• Existing  formal  and  informal  cost  budgeting-related  policies,  procedures,  and  guidelines; 

• Cost  budgeting  tools;  and 

• Reporting  methods. 

7.3.2  Determine  Budget:  Tools  and  Techniques 

7.3.2.1  Cost  Aggregation 

Cost  estimates  are  aggregated  by  work  packages  in  accordance  with  the  WBS.  The  work  package  cost  estimates 
are  then  aggregated  for  the  higher  component  levels  of  the  WBS  (such  as  control  accounts)  and  ultimately  for  the 
entire  project. 

7.3.2.2  Reserve  Analysis 

Budget  reserve  analysis  can  establish  both  the  contingency  reserves  and  the  management  reserves  for  the 
project.  Management  and  contingency  reserves  are  addressed  in  more  detail  in  Section  7. 2.2. 6. 

7.3.2.3  Expert  Judgment 

Expert  judgment,  guided  by  experience  in  an  application  area,  Knowledge  Area,  discipline,  industry,  or  similar 
project,  aids  in  determining  the  budget.  Such  expertise  may  be  provided  by  any  group  or  person  with  specialized 
education,  knowledge,  skill,  experience,  or  training.  Expert  judgment  is  available  from  many  sources,  including,  but 
not  limited  to: 
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• Other  units  within  the  performing  organization, 

• Consultants, 

• Stakeholders,  including  customers, 

• Professional  and  technical  associations,  and 

• Industry  groups. 

7.3.2.4  Historical  Relationships 

Any  historical  relationships  that  result  in  parametric  estimates  or  analogous  estimates  involve  the  use  of  project 
characteristics  (parameters)  to  develop  mathematical  models  to  predict  total  project  costs.  Such  models  may  be 
simple  (e.g.,  residential  home  construction  is  based  on  a certain  cost  per  square  foot  of  space)  or  complex  (e.g.,  one 
model  of  software  development  costing  uses  multiple  separate  adjustment  factors,  each  of  which  has  numerous 
points  within  it). 

Both  the  cost  and  accuracy  of  analogous  and  parametric  models  can  vary  widely.  They  are  most  likely  to  be 
reliable  when: 

• Historical  information  used  to  develop  the  model  is  accurate, 

• Parameters  used  in  the  model  are  readily  quantifiable,  and 

• Models  are  scalable,  such  that  they  work  for  large  projects,  small  projects,  and  phases  of  a project. 

7.3.2.5  Funding  Limit  Reconciliation 

The  expenditure  of  funds  should  be  reconciled  with  any  funding  limits  on  the  commitment  of  funds  forthe  project. 
A variance  between  the  funding  limits  and  the  planned  expenditures  will  sometimes  necessitate  the  rescheduling  of 
work  to  level  out  the  rate  of  expenditures.  This  is  accomplished  by  placing  imposed  date  constraints  for  work  into 
the  project  schedule. 

7.3.3  Determine  Budget:  Outputs 
7.3.3.1  Cost  Baseline 

The  cost  baseline  is  the  approved  version  of  the  time-phased  project  budget,  excluding  any  management  reserves, 
which  can  only  be  changed  through  formal  change  control  procedures  and  is  used  as  a basis  for  comparison  to 
actual  results.  It  is  developed  as  a summation  of  the  approved  budgets  for  the  different  schedule  activities. 
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Figure  7-8  illustrates  the  various  components  of  the  project  budget  and  cost  baseline.  Activity  cost  estimates 
for  the  various  project  activities  along  with  any  contingency  reserves  (Section  7. 2.2. 6)  for  these  activities  are 
aggregated  into  their  associated  work  package  costs.  The  work  package  cost  estimates,  along  with  any  contingency 
reserves  estimated  for  the  work  packages,  are  aggregated  into  control  accounts.  The  summation  of  the  control 
accounts  make  up  the  cost  baseline.  Since  the  cost  estimates  that  make  up  the  cost  baseline  are  directly  tied  to  the 
schedule  activities,  this  enables  a time-phased  view  of  the  cost  baseline,  which  is  typically  displayed  in  the  form  of 
an  S-curve,  as  is  illustrated  in  Figure  7-9. 

Management  reserves  (Section  7. 2.2. 6)  are  added  to  the  cost  baseline  to  produce  the  project  budget.  As  changes 
warranting  the  use  of  management  reserves  arise,  the  change  control  process  is  used  to  obtain  approval  to  move 
the  applicable  management  reserve  funds  into  the  cost  baseline. 
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Figure  7-8.  Project  Budget  Components 
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Figure  7-9.  Cost  Baseline,  Expenditures,  and  Funding  Requirements 

7.3.3.2  Project  Funding  Requirements 

Total  funding  requirements  and  periodic  funding  requirements  (e.g.,  quarterly,  annually)  are  derived  from  the 
cost  baseline.  The  cost  baseline  will  include  projected  expenditures  plus  anticipated  liabilities.  Funding  often  occurs 
in  incremental  amounts  that  are  not  continuous,  and  may  not  be  evenly  distributed,  which  appear  as  steps  as 
shown  in  Figure  7-9.  The  total  funds  required  are  those  included  in  the  cost  baseline,  plus  management  reserves, 
if  any.  Funding  requirements  may  include  the  source(s)  of  the  funding. 

7.3.3.3  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Risk  register, 

• Activity  cost  estimates,  and 

• Project  schedule. 
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7.4  Control  Costs 

Control  Costs  is  the  process  of  monitoring  the  status  of  the  project  to  update  the  project  costs  and  managing 
changes  to  the  cost  baseline.  The  key  benefit  of  this  process  is  that  it  provides  the  means  to  recognize  variance 
from  the  plan  in  order  to  take  corrective  action  and  minimize  risk.  The  inputs,  tools  and  techniques,  and  outputs  of 
this  process  are  depicted  in  Figure  7-1 0.  Figure  7-1 1 depicts  the  data  flow  diagram  of  the  process. 
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Figure  7-10.  Control  Costs:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  7-11.  Control  Costs  Data  Flow  Diagram 
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Updating  the  budget  requires  knowledge  of  the  actual  costs  spent  to  date.  Any  increase  to  the  authorized 
budget  can  only  be  approved  through  the  Perform  Integrated  Change  Control  process  (Section  4.5).  Monitoring  the 
expenditure  of  funds  without  regard  to  the  value  of  work  being  accomplished  for  such  expenditures  has  little  value 
to  the  project,  other  than  to  allow  the  project  team  to  stay  within  the  authorized  funding.  Much  of  the  effort  of  cost 
control  involves  analyzing  the  relationship  between  the  consumption  of  project  funds  to  the  physical  work  being 
accomplished  for  such  expenditures.  The  key  to  effective  cost  control  is  the  management  of  the  approved  cost 
baseline  and  the  changes  to  that  baseline. 

Project  cost  control  includes: 

• Influencing  the  factors  that  create  changes  to  the  authorized  cost  baseline; 

• Ensuring  that  all  change  requests  are  acted  on  in  a timely  manner; 

• Managing  the  actual  changes  when  and  as  they  occur; 

• Ensuring  that  cost  expenditures  do  not  exceed  the  authorized  funding  by  period,  by  WBS  component,  by 
activity,  and  in  total  for  the  project; 

• Monitoring  cost  performance  to  isolate  and  understand  variances  from  the  approved  cost  baseline; 

• Monitoring  work  performance  against  funds  expended; 

• Preventing  unapproved  changes  from  being  included  in  the  reported  cost  or  resource  usage; 

• Informing  appropriate  stakeholders  of  all  approved  changes  and  associated  cost;  and 

• Bringing  expected  cost  overruns  within  acceptable  limits. 

7.4.1  Control  Costs:  Inputs 

7.4.1 .1  Project  Management  Plan 

Described  in  Section  4. 2.3.1 . The  project  management  plan  contains  the  following  information  that  is  used  to 
control  cost: 

• Cost  baseline.  The  cost  baseline  is  compared  with  actual  results  to  determine  if  a change,  corrective 
action,  or  preventive  action  is  necessary. 

• Cost  management  plan.  The  cost  management  plan  describes  how  the  project  costs  will  be  managed 
and  controlled  (Section  7.1 .3.1). 
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7.4.1 .2  Project  Funding  Requirements 

Described  in  Section  7.3. 3.2.  The  project  funding  requirements  include  projected  expenditures  plus  anticipated 
liabilities. 

7.4.1 .3  Work  Performance  Data 

Described  in  Section  4.3. 3.2.  Work  performance  data  includes  information  about  project  progress,  such  as 
which  activities  have  started,  their  progress,  and  which  deliverables  have  finished.  Information  also  includes  costs 
that  have  been  authorized  and  incurred. 

7 

7.4.1 .4  Organizational  Process  Assets 

Described  in  Section  2.1.4.  The  organizational  process  assets  that  can  influence  the  Control  Costs  process 
include,  but  are  not  limited  to: 

• Existing  formal  and  informal  cost  control-related  policies,  procedures,  and  guidelines; 

• Cost  control  tools;  and 

• Monitoring  and  reporting  methods  to  be  used. 

7.4.2  Control  Costs:  Tools  and  Techniques 
7.4.2.1  Earned  Value  Management 

Earned  value  management  (EVM)  is  a methodology  that  combines  scope,  schedule,  and  resource 
measurements  to  assess  project  performance  and  progress.  It  is  a commonly  used  method  of  performance 
measurement  for  projects.  It  integrates  the  scope  baseline  with  the  cost  baseline,  along  with  the  schedule 
baseline,  to  form  the  performance  baseline,  which  helps  the  project  management  team  assess  and  measure 
project  performance  and  progress.  It  is  a project  management  technique  that  requires  the  formation  of  an 
integrated  baseline  against  which  performance  can  be  measured  for  the  duration  of  the  project.  The  principles 
of  EVM  can  be  applied  to  all  projects  in  any  industry.  EVM  develops  and  monitors  three  key  dimensions  for  each 
work  package  and  control  account: 
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• Planned  value.  Planned  value  (PV)  is  the  authorized  budget  assigned  to  scheduled  work.  It  is  the 
authorized  budget  planned  for  the  work  to  be  accomplished  for  an  activity  or  work  breakdown  structure 
component,  not  including  management  reserve.  This  budget  is  allocated  by  phase  over  the  life  of 
the  project,  but  at  a given  moment,  planned  value  defines  the  physical  work  that  should  have  been 
accomplished.  The  total  of  the  PV  is  sometimes  referred  to  as  the  performance  measurement  baseline 
(PMB).  The  total  planned  value  for  the  project  is  also  known  as  budget  at  completion  (BAC). 

• Earned  value.  Earned  value  (EV)  is  a measure  of  work  performed  expressed  in  terms  of  the  budget 
authorized  for  that  work.  It  is  the  budget  associated  with  the  authorized  work  that  has  been  completed. 
The  EV  being  measured  needs  to  be  related  to  the  PMB,  and  the  EV  measured  cannot  be  greater  than  the 
authorized  PV  budget  for  a component.  The  EV  is  often  used  to  calculate  the  percent  complete  of  a project. 
Progress  measurement  criteria  should  be  established  for  each  WBS  component  to  measure  work  in 
progress.  Project  managers  monitor  EV,  both  incrementally  to  determine  current  status  and  cumulatively 
to  determine  the  long-term  performance  trends. 

• Actual  cost.  Actual  cost  (AC)  is  the  realized  cost  incurred  for  the  work  performed  on  an  activity  during 
a specific  time  period.  It  is  the  total  cost  incurred  in  accomplishing  the  work  that  the  EV  measured.  The 
AC  needs  to  correspond  in  definition  to  what  was  budgeted  in  the  PV  and  measured  in  the  EV  (e.g., 
direct  hours  only,  direct  costs  only,  or  all  costs  including  indirect  costs).  The  AC  will  have  no  upper  limit; 
whatever  is  spent  to  achieve  the  EV  will  be  measured. 

Variances  from  the  approved  baseline  will  also  be  monitored: 

• Schedule  variance.  Schedule  variance  (SV)  is  a measure  of  schedule  performance  expressed  as  the 
difference  between  the  earned  value  and  the  planned  value.  It  is  the  amount  by  which  the  project  is  ahead 
or  behind  the  planned  delivery  date,  at  a given  point  in  time.  It  is  a measure  of  schedule  performance  on 
a project.  It  is  equal  to  the  earned  value  (EV)  minus  the  planned  value  (PV).  The  EVM  schedule  variance  is 
a useful  metric  in  that  it  can  indicate  when  a project  is  falling  behind  or  is  ahead  of  its  baseline  schedule. 
The  EVM  schedule  variance  will  ultimately  equal  zero  when  the  project  is  completed  because  all  of  the 
planned  values  will  have  been  earned.  Schedule  variance  is  best  used  in  conjunction  with  critical  path 
methodology  (CPM)  scheduling  and  risk  management.  Equation-.  SV  = EV  - PV 

• Cost  variance.  Cost  variance  (CV)  is  the  amount  of  budget  deficit  or  surplus  at  a given  point  in  time, 
expressed  as  the  difference  between  earned  value  and  the  actual  cost.  It  is  a measure  of  cost  performance 
on  a project.  It  is  equal  to  the  earned  value  (EV)  minus  the  actual  cost  (AC).  The  cost  variance  at  the  end 
of  the  project  will  be  the  difference  between  the  budget  at  completion  (BAC)  and  the  actual  amount  spent. 
The  CV  is  particularly  critical  because  it  indicates  the  relationship  of  physical  performance  to  the  costs 
spent.  Negative  CV  is  often  difficult  for  the  project  to  recover.  Equation-.  CV=  EV  - AC. 
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The  S V and  CV  values  can  be  converted  to  efficiency  indicators  to  reflect  the  cost  and  schedule 
performance  of  any  project  for  comparison  against  all  other  projects  or  within  a portfolio  of  projects.  The 
variances  are  useful  for  determining  project  status. 

• Schedule  performance  index.  The  schedule  performance  index  (SPI)  is  a measure  of  schedule  efficiency 
expressed  as  the  ratio  of  earned  value  to  planned  value.  It  measures  how  efficiently  the  project  team  is 
using  its  time.  It  is  sometimes  used  in  conjunction  with  the  cost  performance  index  (CPI)  to  forecast  the 
final  project  completion  estimates.  An  SPI  value  less  than  1 .0  indicates  less  work  was  completed  than 
was  planned.  An  SPI  greater  than  1 .0  indicates  that  more  work  was  completed  than  was  planned.  Since 
the  SPI  measures  all  project  work,  the  performance  on  the  critical  path  also  needs  to  be  analyzed  to 
determine  whether  the  project  will  finish  ahead  of  or  behind  its  planned  finish  date.  The  SPI  is  equal  to 

the  ratio  of  the  E V to  the  PV.  Equation:  SPI  = EV/PV  7 

• Cost  performance  index.  The  cost  performance  index  (CPI)  is  a measure  of  the  cost  efficiency  of  budgeted 
resources,  expressed  as  a ratio  of  earned  value  to  actual  cost.  It  is  considered  the  most  critical  EVM 
metric  and  measures  the  cost  efficiency  for  the  work  completed.  A CPI  value  of  less  than  1 .0  indicates  a 
cost  overrun  for  work  completed.  A CPI  value  greater  than  1 .0  indicates  a cost  underrun  of  performance 
to  date.  The  CPI  is  equal  to  the  ratio  of  the  E V to  the  AC.  The  indices  are  useful  for  determining  project 
status  and  providing  a basis  for  estimating  project  cost  and  schedule  outcome.  Equation : CPI  = EV/AC 

The  three  parameters  of  planned  value,  earned  value,  and  actual  cost  can  be  monitored  and  reported  on  both 
a period-by-period  basis  (typically  weekly  or  monthly)  and  on  a cumulative  basis.  Figure  7-12  uses  S-curves  to 
display  EV  data  for  a project  that  is  performing  over  budget  and  behind  the  schedule. 


Figure  7-12.  Earned  Value,  Planned  Value,  and  Actual  Costs 
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7.4.2.2  Forecasting 

As  the  project  progresses,  the  project  team  may  develop  a forecast  for  the  estimate  at  completion  (EAC)  that 
may  differ  from  the  budget  at  completion  (BAC)  based  on  the  project  performance.  If  it  becomes  obvious  that  the 
BAC  is  no  longer  viable,  the  project  manager  should  consider  the  forecasted  EAC.  Forecasting  the  EAC  involves 
making  projections  of  conditions  and  events  in  the  project’s  future  based  on  current  performance  information 
and  other  knowledge  available  at  the  time  of  the  forecast.  Forecasts  are  generated,  updated,  and  reissued  based 
on  work  performance  data  (Section  4. 3.3. 2)  that  is  provided  as  the  project  is  executed.  The  work  performance 
information  covers  the  project’s  past  performance  and  any  information  that  could  impact  the  project  in  the  future. 

EACs  are  typically  based  on  the  actual  costs  incurred  for  work  completed,  plus  an  estimate  to  complete  (ETC) 
the  remaining  work.  It  is  incumbent  on  the  project  team  to  predict  what  it  may  encounter  to  perform  the  ETC,  based 
on  its  experience  to  date.  The  EVM  method  works  well  in  conjunction  with  manual  forecasts  of  the  required  EAC 
costs.  The  most  common  EAC  forecasting  approach  is  a manual,  bottom-up  summation  by  the  project  manager 
and  project  team. 

The  project  manager’s  bottom-up  EAC  method  builds  upon  the  actual  costs  and  experience  incurred  for 
the  work  completed,  and  requires  a new  estimate  to  complete  the  remaining  project  work.  Equation:  EAC  = 
AC  + Bottom-up  ETC. 

The  project  manager’s  manual  EAC  is  quickly  compared  with  a range  of  calculated  EACs  representing  various 
risk  scenarios.  When  calculating  EAC  values,  the  cumulative  CPI  and  SPI  values  are  typically  used.  While  EVM  data 
quickly  provide  many  statistical  EACs,  only  three  of  the  more  common  methods  are  described  as  follows: 

• EAC  forecast  for  ETC  work  performed  at  the  budgeted  rate.  This  EAC  method  accepts  the  actual 
project  performance  to  date  (whether  favorable  or  unfavorable)  as  represented  by  the  actual  costs,  and 
predicts  that  all  future  ETC  work  will  be  accomplished  at  the  budgeted  rate.  When  actual  performance 
is  unfavorable,  the  assumption  that  future  performance  will  improve  should  be  accepted  only  when 
supported  by  project  risk  analysis.  Equation : EAC  = AC  + (BAC  - EV) 

• EAC  forecast  for  ETC  work  performed  at  the  present  CPI.  This  method  assumes  what  the  project  has 
experienced  to  date  can  be  expected  to  continue  in  the  future.  The  ETC  work  is  assumed  to  be  performed 
at  the  same  cumulative  cost  performance  index  (CPI)  as  that  incurred  by  the  project  to  date.  Equation-. 
EAC  = BAC  / CPI 
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• EAC  forecast  for  ETC  work  considering  both  SPI  and  CPI  factors.  In  this  forecast,  the  ETC  work  will 
be  performed  at  an  efficiency  rate  that  considers  both  the  cost  and  schedule  performance  indices.  This 
method  is  most  useful  when  the  project  schedule  is  a factor  impacting  the  ETC  effort.  Variations  of  this 
method  weight  the  CPI  and  SPI  at  different  values  (e.g.,  80/20,  50/50,  or  some  other  ratio)  according  to 
the  project  manager’s  judgment.  Equation-.  EAC  = AC  + [(BAC  - EV)  / (CPI  x SPI)] 

Each  of  these  approaches  is  applicable  for  any  given  project  and  will  provide  the  project  management  team  with 
an  “early  warning”  signal  if  the  EAC  forecasts  are  not  within  acceptable  tolerances. 

7.4.2.3  To-Complete  Performance  Index  (TCPI) 

The  to-complete  performance  index  (TCPI)  is  a measure  of  the  cost  performance  that  is  required  to  be  achieved 
with  the  remaining  resources  in  order  to  meet  a specified  management  goal,  expressed  as  the  ratio  of  the  cost  to 
finish  the  outstanding  work  to  the  remaining  budget.  TCPI  is  the  calculated  cost  performance  index  that  is  achieved 
on  the  remaining  work  to  meet  a specified  management  goal,  such  as  the  BAC  or  the  EAC.  If  it  becomes  obvious 
that  the  BAC  is  no  longer  viable,  the  project  manager  should  consider  the  forecasted  EAC.  Once  approved,  the  EAC 
may  replace  the  BAC  in  the  TCPI  calculation.  The  equation  for  the  TCPI  based  on  the  BAC:  (BAC  - EV)  / (BAC  - AC). 

The  TCPI  is  conceptually  displayed  in  Figure  7-13.  The  equation  for  the  TCPI  is  shown  in  the  lower  left  as  the 
work  remaining  (defined  as  the  BAC  minus  the  EV)  divided  by  the  funds  remaining  (which  can  be  either  the  BAC 
minus  the  AC,  or  the  EAC  minus  the  AC). 

If  the  cumulative  CPI  falls  below  the  baseline  (as  shown  in  Figure  7-1 3),  all  future  work  of  the  project  will  need 
to  be  performed  immediately  in  the  range  of  the  TCPI  (BAC)  (as  reflected  in  the  top  line  of  Figure  7-13)  to  stay 
within  the  authorized  BAC.  Whether  this  level  of  performance  is  achievable  is  a judgment  call  based  on  a number 
of  considerations,  including  risk,  schedule,  and  technical  performance.  This  level  of  performance  is  displayed  as 
the  TCPI  (EAC)  line.  The  equation  for  the  TCPI  based  on  the  EAC:  (BAC  - EV)  / (EAC  - AC).  The  EVM  formulas  are 
provided  in  Table  7-1. 
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7.4.2.4  Performance  Reviews 

Performance  reviews  compare  cost  performance  over  time,  schedule  activities  or  work  packages  overrunning 
and  underrunning  the  budget,  and  estimated  funds  needed  to  complete  work  in  progress.  If  EVM  is  being  used,  the 
following  information  is  determined: 

• Variance  analysis.  Variance  analysis,  as  used  in  EVM,  is  the  explanation  (cause,  impact,  and  corrective 
actions)  for  cost  (CV  = EV  - AC),  schedule  (S V = EV  - PV),  and  variance  at  completion  (VAC  = BAC  - EAC) 
variances.  Cost  and  schedule  variances  are  the  most  frequently  analyzed  measurements.  For  projects 
not  using  earned  value  management,  similar  variance  analyses  can  be  performed  by  comparing  planned 
activity  cost  against  actual  activity  cost  to  identify  variances  between  the  cost  baseline  and  actual 
project  performance.  Further  analysis  can  be  performed  to  determine  the  cause  and  degree  of  variance 
relative  to  the  schedule  baseline  and  any  corrective  or  preventative  actions  needed.  Cost  performance 
measurements  are  used  to  assess  the  magnitude  of  variation  to  the  original  cost  baseline.  An  important 
aspect  of  project  cost  control  includes  determining  the  cause  and  degree  of  variance  relative  to  the 
cost  baseline  (Section  7.3. 3.1)  and  deciding  whether  corrective  or  preventive  action  is  required.  The 
percentage  range  of  acceptable  variances  will  tend  to  decrease  as  more  work  is  accomplished. 
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• Trend  analysis.  Trend  analysis  examines  project  performance  over  time  to  determine  if  performance  is 
improving  or  deteriorating.  Graphical  analysis  techniques  are  valuable  for  understanding  performance 
to  date  and  for  comparison  to  future  performance  goals  in  the  form  of  BAC  versus  EAC  and  completion 
dates. 

• Earned  value  performance.  Earned  value  performance  compares  the  performance  measurement 
baseline  to  actual  schedule  and  cost  performance.  If  EVM  is  not  being  used,  then  the  analysis  of  the  cost 
baseline  against  actual  costs  for  the  work  performed  is  used  for  cost  performance  comparisons. 
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Table  7-1.  Earned  Value  Calculations  Summary  Table 


Earned  Value  Analysis 


Abbreviation 

Name 

Lexicon  Definition 

How  Used 

Equation 

Interpretation  of  Result 

P V 

Planned 

Value 

The  authorized  budget  assigned  to 
scheduled  work. 

The  value  of  the  work  planned  to  be 
completed  to  a point  in  time,  usually 
the  data  date,  or  project  completion. 

E V 

Earned  Value 

The  measure  of  work  performed 
expressed  in  terms  of  the  budget 
authorized  for  that  work. 

The  planned  value  of  all  the  work 
completed  (earned)  to  a point  in 
time,  usually  the  data  date,  without 
reference  to  actual  costs. 

EV  = sum  of  the  planned 
value  of  completed  work 

AC 

Actual  Cost 

The  realized  cost  incurred  for  the 
work  performed  on  an  activity  during 
a specific  time  period. 

The  actual  cost  of  all  the  work 
completed  to  a point  in  time,  usually 
the  data  date. 

BAC 

Budget  at 
Completion 

The  sum  of  all  budgets  established 
for  the  work  to  be  performed. 

The  value  of  total  planned  work,  the 
project  cost  baseline. 

CV 

Cost  Variance 

The  amount  of  budget  deficit  or 
surplus  at  a given  point  in  time, 
expressed  as  the  difference  between 
the  earned  value  and  the  actual  cost. 

The  difference  between  the  value  of 
work  completed  to  a point  in  time, 
usually  the  data  date,  and  the  actual 
costs  to  the  same  point  in  time. 

CV  = EV  - AC 

Positive  = Under  planned  cost 

Neutral  = On  planned  cost 

Negative  = Over  planned  cost 

SV 

Schedule 

Variance 

The  amount  by  which  the  project  is 
ahead  or  behind  the  planned 
delivery  date,  at  a given  point  in 
time,  expressed  as  the  difference 
between  the  earned  value  and  the 
planned  value. 

The  difference  between  the  work 
completed  to  a point  in  time,  usually 
the  data  date,  and  the  work  planned 
to  be  completed  to  the  same  point 
in  time. 

SV  = EV  - PV 

Positive  = Ahead  of  Schedule 

Neutral  = On  schedule 

Negative  = Behind  Schedule 

VAC 

Variance  at 
Completion 

A projection  of  the  amount  of  budget 
deficit  or  surplus,  expressed  as  the 
difference  between  the  budget  at 
completion  and  the  estimate  at 
completion. 

The  estimated  difference  in  cost  at 
the  completion  of  the  project. 

VAC  = BAC  - EAC 

Positive  = Under  planned  cost 

Neutral  = On  planned  cost 

Negative  = Over  planned  cost 

CPI 

Cost 

Performance 

Index 

A measure  of  the  cost  efficiency  of 
budgeted  resources 
expressed  as  the  ratio  of  earned 
value  to  actual  cost. 

A CPI  of  1.0  means  the  project  is 
exactly  on  budget,  that  the  work 
actually  done  so  far  is  exactly  the 
same  as  the  cost  so  far.  Other  values 
show  the  percentage  of  how  much 
costs  are  over  or  under  the  budgeted 
amount  for  work  accomplished. 

CPI  = EV/AC 

Greater  than  1.0  = Under  planned 
cost 

Exactly  1.0  = On  planned  cost 

Less  than  1.0  = Over  planned  cost 

SPI 

Schedule 

Performance 

Index 

A measure  of  schedule  efficiency 
expressed  as  the  ratio  of  earned 
value  to  planned  value. 

An  SPI  of  1.0  means  that  the  project 
is  exactly  on  schedule,  that  the  work 
actually  done  so  far  is  exactly  the 
same  as  the  work  planned  to  be 
done  so  far.  Other  values  show  the 
percentage  of  how  much  costs  are 
over  or  under  the  budgeted  amount 
for  work  planned. 

SPI  = EV/PV 

Greater  than  1.0  = Ahead  of 
schedule 

Exactly  1.0  = On  schedule 

Less  than  1.0  = Behind  schedule 

EAC 

Estimate  At 
Completion 

The  expected  total  cost  of  com- 
pleting all  work  expressed  as  the 
sum  of  the  actual  cost  to  date  and 
the  estimate  to  complete. 

If  the  CPI  is  expected  to  be  the  same 
for  the  remainder  of  the  project,  EAC 
can  be  calculated  using: 

If  future  work  will  be  accomplished 
at  the  planned  rate,  use: 

If  the  initial  plan  is  no  longer  valid, 

EAC  = BAC/CPI 

EAC  = AC  + BAC  - EV 

EAC  = AC  + Bottom-up  ETC 

If  both  the  CPI  and  SPI  influence  the 
remaining  work,  use: 

EAC  = AC  + [(BAC  - EV)/ 

(CPI  x SPI)] 

ETC 

Estimate  to 
Complete 

The  expected  cost  to  finish  all  the 
remaining  project  work. 

Assuming  work  is  proceeding  on 
plan,  the  cost  of  completing  the 
remaining  authorized  work  can  be 
calculated  using: 

Reestimate  the  remaining  work  from 
the  bottom  up. 

ETC  = EAC -AC 

ETC  = Reestimate 

TCPI 

To  Complete 
Performance 
Index 

A measure  of  the  cost  performance 
that  must  be  achieved  with  the 
remaining  resources  in  order  to  meet 
a specified  management  goal, 
expressed  as  the  ratio  of  the  cost  to 
finish  the  outstanding  work  to  the 
budget  available. 

The  efficiency  that  must  be 
maintained  in  order  to  complete  on 
plan. 

The  efficiency  that  must  be 
maintained  in  order  to  complete  the 
current  EAC. 

TCPI  = ( BAC  - EV )/( BAC  - AC ) 

TCPI  = (BAC-EV)/(EAC-AC) 

Greater  than  1.0  = Harder  to 
complete 

Exactly  1.0  = Same  to  complete 

Less  than  1.0  = Easier  to  complete 

Greater  than  1.0  = Harder  to 
complete 

Exactly  1.0  = Same  to  complete 

Less  than  1.0  = Easier  to  complete 
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7.4.2.5  Project  Management  Software 

Project  management  software  is  often  used  to  monitor  the  three  EVM  dimensions  (PV,  EV,  and  AC),  to  display 
graphical  trends,  and  to  forecast  a range  of  possible  final  project  results. 

7.4.2.6  Reserve  Analysis 

During  cost  control,  reserve  analysis  is  used  to  monitor  the  status  of  contingency  and  management  reserves 
for  the  project  to  determine  if  these  reserves  are  still  needed  or  if  additional  reserves  need  to  be  requested. 
As  work  on  the  project  progresses,  these  reserves  may  be  used  as  planned  to  cover  the  cost  of  risk  mitigation 
events  or  other  contingencies.  Or,  if  the  probable  risk  events  do  not  occur,  the  unused  contingency  reserves 
may  be  removed  from  the  project  budget  to  free  up  resources  for  other  projects  or  operations.  Additional  risk 
analysis  during  the  project  may  reveal  a need  to  request  that  additional  reserves  be  added  to  the  project  budget. 
Management  and  contingency  reserves  are  addressed  in  more  detail  in  Section  7. 2. 2. 6. 

7.4.3  Control  Costs:  Outputs 

7.4.3.1  Work  Performance  Information 

The  calculated  CV,  S V,  CPI,  SPI,  TCPI,  and  VAC  values  for  WBS  components,  in  particular  the  work  packages  and 
control  accounts,  are  documented  and  communicated  to  stakeholders. 

7.4.3.2  Cost  Forecasts 

Either  a calculated  EAC  value  or  a bottom-up  EAC  value  is  documented  and  communicated  to  stakeholders. 

7.4.3.3  Change  Requests 

Analysis  of  project  performance  may  result  in  a change  request  to  the  cost  baseline  or  other  components  of  the 
project  management  plan.  Change  requests  may  include  preventive  or  corrective  actions,  and  are  processed  for 
review  and  disposition  through  the  Perform  Integrated  Change  Control  process  (Section  4.5). 

7.4.3.4  Project  Management  Plan  Updates 

Elements  of  the  project  management  plan  that  may  be  updated  include,  but  are  not  limited  to: 
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• Cost  baseline.  Changes  to  the  cost  baseline  are  incorporated  in  response  to  approved  changes  in  scope, 
activity  resources,  or  cost  estimates.  In  some  cases,  cost  variances  can  be  so  severe  that  a revised  cost 
baseline  is  needed  to  provide  a realistic  basis  for  performance  measurement. 

• Cost  management  plan.  Changes  to  the  cost  management  plan,  such  as  changes  to  control  thresholds 
or  specified  levels  of  accuracy  required  in  managing  the  project’s  cost,  are  incorporated  in  response  to 
feedback  from  relevant  stakeholders. 

7.4.3.5  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Cost  estimates,  and 

• Basis  of  estimates. 

7.4.3.6  Organizational  Process  Assets  Updates 

Organizational  process  assets  that  may  be  updated  include,  but  are  not  limited  to: 

• Causes  of  variances, 

• Corrective  action  chosen  and  the  reasons, 

• Financial  databases,  and 

• Other  types  of  lessons  learned  from  project  cost  control. 
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8 

PROJECT  QUALITY  MANAGEMENT 


Project  Quality  Management  includes  the  processes  and  activities  of  the  performing  organization  that 
determine  quality  policies,  objectives,  and  responsibilities  so  that  the  project  will  satisfy  the  needs  for  which  it  was 
undertaken.  Project  Quality  Management  uses  policies  and  procedures  to  implement,  within  the  project’s  context, 
the  organization’s  quality  management  system  and,  as  appropriate,  it  supports  continuous  process  improvement 
activities  as  undertaken  on  behalf  of  the  performing  organization.  Project  Quality  Management  works  to  ensure  that 
the  project  requirements,  including  product  requirements,  are  met  and  validated.  8 

Figure  8-1  provides  an  overview  of  the  Project  Quality  Management  processes,  which  include: 

8.1  Plan  Quality  Management — The  process  of  identifying  quality  requirements  and/or  standards  for  the 
project  and  its  deliverables  and  documenting  how  the  project  will  demonstrate  compliance  with  quality 
requirements. 

8.2  Perform  Quality  Assurance — The  process  of  auditing  the  quality  requirements  and  the  results  from 
quality  control  measurements  to  ensure  that  appropriate  quality  standards  and  operational  definitions 
are  used. 

8.3  Control  Quality — The  process  of  monitoring  and  recording  results  of  executing  the  quality  activities 
to  assess  performance  and  recommend  necessary  changes. 

These  processes  interact  with  each  other  and  with  processes  in  other  Knowledge  Areas  as  described  in 
detail  in  Section  3 and  Annex  A1 . 

Project  Quality  Management  addresses  the  management  of  the  project  and  the  deliverables  of  the  project. 

It  applies  to  all  projects,  regardless  of  the  nature  of  their  deliverables.  Quality  measures  and  techniques  are  specific 
to  the  type  of  deliverables  being  produced  by  the  project.  For  example,  the  project  quality  management  of  software 
deliverables  may  use  different  approaches  and  measures  from  those  used  when  building  a nuclear  power  plant.  In 
either  case,  failure  to  meet  the  quality  requirements  can  have  serious,  negative  consequences  for  any  or  all  of  the 
project’s  stakeholders.  For  example: 
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• Meeting  customer  requirements  by  overworking  the  project  team  may  result  in  decreased  profits  and 
increased  project  risks,  employee  attrition,  errors,  or  rework. 

• Meeting  project  schedule  objectives  by  rushing  planned  quality  inspections  may  result  in  undetected 
errors,  decreased  profits,  and  increased  post-implementation  risks. 

Quality  and  grade  are  not  the  same  concepts.  Quality  as  a delivered  performance  or  result  is  “the  degree  to  which 
a set  of  inherent  characteristics  fulfill  requirements”  (ISO  9000)  [1 0],  Grade  as  a design  intent  is  a category  assigned 
to  deliverables  having  the  same  functional  use  but  different  technical  characteristics.  The  project  manager  and  the 
project  management  team  are  responsible  for  managing  the  tradeoffs  associated  with  delivering  the  required  levels 
of  both  quality  and  grade.  While  a quality  level  that  fails  to  meet  quality  requirements  is  always  a problem,  a low 
grade  of  quality  may  not  be  a problem.  For  example: 

• It  may  not  be  a problem  if  a suitable  low-grade  software  product  (one  with  a limited  number  of  features) 
is  of  high  quality  (no  obvious  defects,  readable  manual).  In  this  example,  the  product  would  be  appropriate 
for  its  general  purpose  of  use. 

• It  may  be  a problem  if  a high-grade  software  product  (one  with  numerous  features)  is  of  low  quality 
(many  defects,  poorly  organized  user  documentation).  In  essence,  its  high-grade  feature  set  would  prove 
ineffective  and/or  inefficient  due  to  its  low  quality. 

The  project  management  team  should  determine  the  appropriate  levels  of  accuracy  and  precision  for  use  in  the 
quality  management  plan.  Precision  is  a measure  of  exactness.  For  example,  the  magnitude  for  each  increment 
on  the  measurement’s  number  line  is  the  interval  that  determines  the  measurement’s  precision — the  greater  the 
number  of  increments,  the  greater  the  precision.  Accuracy  is  an  assessment  of  correctness.  For  example,  if  the 
measured  value  of  an  item  is  very  close  to  the  true  value  of  the  characteristic  being  measured,  the  measurement 
is  more  accurate.  An  illustration  of  this  concept  is  the  comparison  of  archery  targets.  Arrows  clustered  tightly 
in  one  area  of  the  target,  even  if  they  are  not  clustered  in  the  bull’s-eye,  are  considered  to  have  high  precision. 
Targets  where  the  arrows  are  more  spread  out  but  equidistant  from  the  bull’s-eye  are  considered  to  have  the  same 
degree  of  accuracy.  Targets  where  the  arrows  are  both  tightly  grouped  and  within  the  bull’s-eye  are  considered  to 
be  both  accurate  and  precise.  Precise  measurements  are  not  necessarily  accurate  measurements,  and  accurate 
measurements  are  not  necessarily  precise  measurements. 

The  basic  approach  to  project  quality  management  as  described  in  this  section  is  intended  to  be  compatible 
with  International  Organization  for  Standardization  (ISO)  quality  standards.  Every  project  should  have  a quality 
management  plan.  Project  teams  should  follow  the  quality  management  plan  and  should  have  data  to  demonstrate 
compliance  with  the  plan. 
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In  the  context  of  achieving  ISO  compatibility,  modern  quality  management  approaches  seek  to  minimize  variation 
and  to  deliver  results  that  meet  defined  requirements.  These  approaches  recognize  the  importance  of: 

• Customer  satisfaction.  Understanding,  evaluating,  defining,  and  managing  requirements  so  that 
customer  expectations  are  met.  This  requires  a combination  of  conformance  to  requirements  (to  ensure 
the  project  produces  what  it  was  created  to  produce)  and  fitness  for  use  (the  product  or  service  needs  to 
satisfy  the  real  needs). 

• Prevention  over  inspection.  Quality  should  be  planned,  designed,  and  built  into — not  inspected  into  the 
project’s  management  or  the  project’s  deliverables.  The  cost  of  preventing  mistakes  is  generally  much 
less  than  the  cost  of  correcting  mistakes  when  they  are  found  by  inspection  or  during  usage. 

• Continuous  improvement.  The  PDCA  (plan-do-check-act)  cycle  is  the  basis  for  quality  improvement  as 
defined  by  Shewhart  and  modified  by  Deming.  In  addition,  quality  improvement  initiatives  such  as  Total 
Quality  Management  (TQM),  Six  Sigma,  and  Lean  Six  Sigma  could  improve  the  quality  of  the  project’s 
management  as  well  as  the  quality  of  the  project’s  product.  Commonly  used  process  improvement  models 
include  Malcolm  Baldrige,  Organizational  Project  Management  Maturity  Model  (0PM3®),  and  Capability 
Maturity  Model  Integrated  (CMMI®). 

• Management  Responsibility.  Success  requires  the  participation  of  all  members  of  the  project  team. 
Nevertheless,  management  retains,  within  its  responsibility  for  quality,  a related  responsibility  to  provide 
suitable  resources  at  adequate  capacities. 

• Cost  of  quality  (COQ).  Cost  of  quality  refers  to  the  total  cost  of  the  conformance  work  and  the 
nonconformance  work  that  should  be  done  as  a compensatory  effort  because,  on  the  first  attempt  to 
perform  that  work,  the  potential  exists  that  some  portion  of  the  required  work  effort  may  be  done  or  has 
been  done  incorrectly.  The  costs  for  quality  work  may  be  incurred  throughout  the  deliverable’s  life  cycle. 
For  example,  decisions  made  by  the  project  team  can  impact  the  operational  costs  associated  with  using 
a completed  deliverable.  Post-project  quality  costs  may  be  incurred  because  of  product  returns,  warranty 
claims,  and  recall  campaigns.  Therefore,  because  of  the  temporary  nature  of  projects  and  the  potential 
benefits  that  may  be  derived  from  reducing  the  post-project  cost  of  quality,  sponsoring  organizations 
may  choose  to  invest  in  product  quality  improvement.  These  investments  generally  are  made  in  the  areas 
of  conformance  work  that  act  to  prevent  defects  or  act  to  mitigate  the  costs  of  defects  by  inspecting 
out  nonconforming  units.  Refer  to  Figure  8-2  and  Section  8.1 .2.2.  Moreover,  the  issues  related  to  post- 
project COQ  should  be  the  concern  of  program  management  and  portfolio  management  such  that  project, 
program,  and  portfolio  management  offices  should  apply  appropriate  reviews,  templates,  and  funding 
allocations  for  this  purpose. 
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Figure  8-1 . Project  Quality  Management  Overview 
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Figure  8-2.  Fundamental  Relationships  of  Quality  Assurance  and  Control  Quality  to  the  IPECC,  PDCA,  Cost 
of  Quality  Models  and  Project  Management  Process  Groups 


8.1  Plan  Quality  Management 

Plan  Quality  Management  is  the  process  of  identifying  quality  requirements  and/or  standards  for  the  project  and 
its  deliverables,  and  documenting  how  the  project  will  demonstrate  compliance  with  relevant  quality  requirements. 
The  key  benefit  of  this  process  is  that  it  provides  guidance  and  direction  on  how  quality  will  be  managed  and 
validated  throughout  the  project.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in 
Figure  8-3.  Figure  8-4  depicts  the  data  flow  diagram  of  the  process. 
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Figure  8-3.  Plan  Quality  Management  Inputs,  Tools  & Techniques,  and  Outputs 


Figure  8-4.  Plan  Quality  Management  Data  Flow  Diagram 
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Quality  planning  should  be  performed  in  parallel  with  the  other  planning  processes.  For  example,  proposed 
changes  in  the  deliverables  to  meet  identified  quality  standards  may  require  cost  or  schedule  adjustments  and  a 
detailed  risk  analysis  of  the  impact  to  plans. 

The  quality  planning  techniques  discussed  here  are  those  used  most  frequently  on  projects.  There  are  many 
others  that  may  be  useful  on  certain  projects  or  in  some  application  areas. 

8.1.1  Plan  Quality  Management:  Inputs 

8.1 .1.1  Project  Management  Plan 

Described  in  Section  4. 2.3.1.  The  project  management  plan  is  used  to  develop  the  quality  management  plan. 
The  information  used  for  the  development  of  the  quality  management  plan  includes,  but  is  not  limited  to: 

• Scope  baseline.  The  scope  baseline  (Section  5. 4.3.1 ) includes: 

o Project  scope  statement.  The  project  scope  statement  contains  the  project  description,  major 
project  deliverables,  and  acceptance  criteria.  The  product  scope  often  contains  details  of 
technical  issues  and  other  concerns  that  can  affect  quality  planning  and  that  should  have  been 
identified  as  a result  of  the  planning  processes  in  Project  Scope  Management.  The  definition  of 
acceptance  criteria  may  significantly  increase  or  decrease  quality  costs  and  therefore,  project 
costs.  Satisfying  all  acceptance  criteria  that  the  needs  of  the  sponsor  and/or  customer  have 
been  met. 

o Work  breakdown  structure  (WBS).  The  WBS  identifies  the  deliverables  and  the  work  packages 
used  to  measure  project  performance. 

o WBS  dictionary.  The  WBS  dictionary  provides  detailed  information  for  WBS  elements. 

• Schedule  baseline.  The  schedule  baseline  documents  the  accepted  schedule  performance  measures, 
including  start  and  finish  dates  (Section  6. 6.3.1). 

• Cost  baseline.  The  cost  baseline  documents  the  accepted  time  interval  being  used  to  measure  cost 
performance  (Section  7. 3.3.1). 

• Other  management  plans.  These  plans  contribute  to  the  overall  project  quality  and  may  highlight 
actionable  areas  of  concern  with  regard  to  the  project’s  quality. 
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8.1 .1.2  Stakeholder  Register 

Described  in  Section  13.1.3.1.  The  stakeholder  register  aids  in  identifying  those  stakeholders  possessing  a 
particular  interest  in,  or  having  an  impact  on,  quality. 

8.1 .1.3  Risk  Register 

Described  in  Section  11.2.3.1.  The  risk  register  contains  information  on  threats  and  opportunities  that  may 
impact  quality  requirements. 

8.1 .1 .4  Requirements  Documentation 

Described  in  Section  5. 2.3.1.  Requirements  documentation  captures  the  requirements  that  the  project  shall 
meet  pertaining  to  stakeholder  expectations.  The  components  of  the  requirements  documentation  include,  but  are 
not  limited  to,  project  (including  product)  and  quality  requirements.  The  requirements  are  used  by  the  project  team 
to  help  plan  how  quality  control  will  be  implemented  on  the  project. 

8.1 .1 .5  Enterprise  Environmental  Factors 

Described  in  Section  2.1.5.  The  enterprise  environmental  factors  that  influence  the  Plan  Quality  Management 
process  include,  but  are  not  limited  to: 

• Governmental  agency  regulations; 

• Rules,  standards,  and  guidelines  specific  to  the  application  area; 

• Working  or  operating  conditions  of  the  project  or  its  deliverables  that  may  affect  project  quality;  and 

• Cultural  perceptions  that  may  influence  expectations  about  quality. 

8.1 .1 .6  Organizational  Process  Assets 

Described  in  Section  2.1.4.  The  organizational  process  assets  that  influence  the  Plan  Quality  Management 
process  include,  but  are  not  limited  to: 

• Organizational  quality  policies,  procedures,  and  guidelines.  The  performing  organization’s  quality  policy, 
as  endorsed  by  senior  management,  sets  the  organization’s  intended  direction  on  implementing  its  quality 
management  approach; 

• Historical  databases;  and 

• Lessons  learned  from  previous  phases  or  projects. 
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8.1.2  Plan  Quality  Management:  Tools  and  Techniques 


8.1 .2.1  Cost-Benefit  Analysis 

The  primary  benefits  of  meeting  quality  requirements  include  less  rework,  higher  productivity,  lower  costs, 
increased  stakeholder  satisfaction,  and  increased  profitability.  A cost-benefit  analysis  for  each  quality  activity 
compares  the  cost  of  the  quality  step  to  the  expected  benefit. 

8.1 .2.2  Cost  of  Quality  (COQ) 

Cost  of  quality  includes  all  costs  incurred  over  the  life  of  the  product  by  investment  in  preventing  nonconformance 
to  requirements,  appraising  the  product  or  service  for  conformance  to  requirements,  and  failing  to  meet  requirements 
(rework).  Failure  costs  are  often  categorized  into  internal  (found  by  the  project)  and  external  (found  by  the  customer). 
Failure  costs  are  also  called  cost  of  poor  quality.  Figure  8-5  provides  some  examples  to  consider  in  each  area. 


Cost  of  Conformance  Cost  of  Nonconformance 


Internal  Failure  Costs 

(Failures  found  by  the  project) 

• Rework 

• Scrap 

External  Failure  Costs 

(Failures  found  by  the  customer) 

• Liabilities 

• Warranty  work 

• Lost  business 


Money  spent  during  and  after 
the  project  because  of  failures 

Money  spent  during  the  project 

to  avoid  failures 


Prevention  Costs 

(Build  a quality  product) 

• Training 

• Document  processes 

• Equipment 

• Time  to  do  it  right 

Appraisal  Costs 

(Assess  the  quality) 

• Testing 

• Destructive  testing  loss 

• Inspections 


Figure  8-5.  Cost  of  Quality 
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8.1 .2.3  Seven  Basic  Quality  Tools 

The  seven  basic  quality  tools,  also  known  in  the  industry  as  7QC  Tools,  are  used  within  the  context  of  the  PDCA 
Cycle  to  solve  quality-related  problems.  As  conceptually  illustrated  in  Figure  8-7,  the  seven  basic  quality  tools  are: 

• Cause-and-effect  diagrams,  which  are  also  known  as  fishbone  diagrams  or  as  Ishikawa  diagrams.  The 
problem  statement  placed  at  the  head  of  the  fishbone  is  used  as  a starting  point  to  trace  the  problem’s 
source  back  to  its  actionable  root  cause.  The  problem  statement  typically  describes  the  problem  as  a gap 
to  be  closed  or  as  an  objective  to  be  achieved.  The  causes  are  found  by  looking  at  the  problem  statement 
and  asking  “why”  until  the  actionable  root  cause  has  been  identified  or  until  the  reasonable  possibilities 
on  each  fishbone  have  been  exhausted.  Fishbone  diagrams  often  prove  useful  in  linking  the  undesirable 
effects  seen  as  special  variation  to  the  assignable  cause  upon  which  project  teams  should  implement 
corrective  actions  to  eliminate  the  special  variation  detected  in  a control  chart. 

• Flowcharts,  which  are  also  referred  to  as  process  maps  because  they  display  the  sequence  of  steps  and 
the  branching  possibilities  that  exist  for  a process  that  transforms  one  or  more  inputs  into  one  or  more 
outputs.  Flowcharts  show  the  activities,  decision  points,  branching  loops,  parallel  paths,  and  the  overall 
order  of  processing  by  mapping  the  operational  details  of  procedures  that  exist  within  a horizontal  value 
chain  of  a SIPOC  model  (Figure  8-6).  Flowcharts  may  prove  useful  in  understanding  and  estimating 
the  cost  of  quality  in  a process.  This  is  obtained  by  using  the  workflow  branching  logic  and  associated 
relative  frequencies  to  estimate  expected  monetary  value  for  the  conformance  and  nonconformance 
work  required  to  deliver  the  expected  conforming  output. 
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NOTE:  The  components  of  this  diagram  are  flexible  and  can  take  any  direction  depending  upon  the  circumstance. 


Figure  8-6.  The  SIPOC  Model 

• Checksheets,  which  are  also  known  as  tally  sheets  and  may  be  used  as  a checklist  when  gathering  data. 
Checksheets  are  used  to  organize  facts  in  a manner  that  will  facilitate  the  effective  collection  of  useful 
data  about  a potential  quality  problem.  They  are  especially  useful  for  gathering  attributes  data  while 
performing  inspections  to  identify  defects.  For  example,  data  about  the  frequencies  or  consequences  of 
defects  collected  in  checksheets  are  often  displayed  using  Pareto  diagrams. 

• Pareto  diagrams,  exist  as  a special  form  of  vertical  bar  chart  and  are  used  to  identify  the  vital  few  sources 
that  are  responsible  for  causing  most  of  a problem’s  effects.  The  categories  shown  on  the  horizontal 
axis  exist  as  a valid  probability  distribution  that  accounts  for  100%  of  the  possible  observations.  The 
relative  frequencies  of  each  specified  cause  listed  on  the  horizontal  axis  decrease  in  magnitude  until  the 
default  source  named  “other  accounts  for  any  nonspecified  causes.  Typically,  the  Pareto  diagram  will  be 
organized  into  categories  that  measure  either  frequencies  or  consequences. 
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• Histograms,  are  a special  form  of  bar  chart  and  are  used  to  describe  the  central  tendency,  dispersion,  and 
shape  of  a statistical  distribution.  Unlike  the  control  chart,  the  histogram  does  not  consider  the  influence 
of  time  on  the  variation  that  exists  within  a distribution. 

• Control  charts,  are  used  to  determine  whether  or  not  a process  is  stable  or  has  predictable  performance. 
Upper  and  lower  specification  limits  are  based  on  requirements  of  the  agreement.  They  reflect 
the  maximum  and  minimum  values  allowed.  There  may  be  penalties  associated  with  exceeding  the 
specification  limits.  Upper  and  lower  control  limits  are  different  from  specification  limits.  The  control 
limits  are  determined  using  standard  statistical  calculations  and  principles  to  ultimately  establish  the 
natural  capability  for  a stable  process.  The  project  manager  and  appropriate  stakeholders  may  use  the 
statistically  calculated  control  limits  to  identify  the  points  at  which  corrective  action  will  be  taken  to 
prevent  unnatural  performance.  The  corrective  action  typically  seeks  to  maintain  the  natural  stability  of  a 
stable  and  capable  process.  For  repetitive  processes,  the  control  limits  are  generally  set  at  ±3  s around 
a process  mean  that  has  been  set  at  0 s.  A process  is  considered  out  of  control  when:  (1)  a data  point 
exceeds  a control  limit;  (2)  seven  consecutive  plot  points  are  above  the  mean;  or  (3)  seven  consecutive 
plot  points  are  below  the  mean.  Control  charts  can  be  used  to  monitor  various  types  of  output  variables. 
Although  used  most  frequently  to  track  repetitive  activities  required  for  producing  manufactured  lots, 
control  charts  may  also  be  used  to  monitor  cost  and  schedule  variances,  volume,  and  frequency  of  scope 
changes,  or  other  management  results  to  help  determine  if  the  project  management  processes  are  in 
control. 

• Scatter  diagrams,  plot  ordered  pairs  (X,  Y)  and  are  sometimes  called  correlation  charts  because  they  seek 
to  explain  a change  in  the  dependent  variable,  Y,  in  relationship  to  a change  observed  in  the  corresponding 
independent  variable,  X.  The  direction  of  correlation  may  be  proportional  (positive  correlation),  inverse 
(negative  correlation),  or  a pattern  of  correlation  may  not  exist  (zero  correlation).  If  correlation  can  be 
established,  a regression  line  can  be  calculated  and  used  to  estimate  how  a change  to  the  independent 
variable  will  influence  the  value  of  the  dependent  variable. 
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Figure  8-7.  Storyboard  Illustrating  a Conceptual  Example  of  Each  of  the  Seven  Basic  Quality  Tools 

8.1 .2.4  Benchmarking 

Benchmarking  involves  comparing  actual  or  planned  project  practices  to  those  of  comparable  projects  to  identify 
best  practices,  generate  ideas  for  improvement,  and  provide  a basis  for  measuring  performance. 

Benchmarked  projects  may  exist  within  the  performing  organization  or  outside  of  it,  or  can  be  within  the  same 
application  area.  Benchmarking  allows  for  analogies  from  projects  in  a different  application  area  to  be  made. 

8.1 .2.5  Design  of  Experiments 

Design  of  experiments  (DOE)  is  a statistical  method  for  identifying  which  factors  may  influence  specific  variables 
of  a product  or  process  under  development  or  in  production.  DOE  may  be  used  during  the  Plan  Quality  Management 
process  to  determine  the  number  and  type  of  tests  and  their  impact  on  cost  of  quality. 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK®  Guide)  - Fifth  Edition 


239 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


8 - PROJECT  QUALITY  MANAGEMENT 


DOE  also  plays  a role  in  optimizing  products  or  processes.  DOE  is  used  to  reduce  the  sensitivity  of  product 
performance  to  sources  of  variations  caused  by  environmental  or  manufacturing  differences.  One  important  aspect 
of  this  technique  is  that  it  provides  a statistical  framework  for  systematically  changing  all  of  the  important  factors, 
rather  than  changing  the  factors  one  at  a time.  Analysis  of  the  experimental  data  should  provide  the  optimal 
conditions  for  the  product  or  process,  highlight  the  factors  that  influence  the  results,  and  reveal  the  presence  of 
interactions  and  synergy  among  the  factors.  For  example,  automotive  designers  use  this  technique  to  determine 
which  combination  of  suspension  and  tires  will  produce  the  most  desirable  ride  characteristics  at  a reasonable  cost. 

8.1 .2.6  Statistical  Sampling 

Statistical  sampling  involves  choosing  part  of  a population  of  interest  for  inspection  (for  example,  selecting  ten 
engineering  drawings  at  random  from  a list  of  seventy-five).  Sample  frequency  and  sizes  should  be  determined  during 
the  Plan  Quality  Management  process  so  the  cost  of  quality  will  include  the  number  of  tests,  expected  scrap,  etc. 

There  is  a substantial  body  of  knowledge  on  statistical  sampling.  In  some  application  areas,  it  may  be  necessary 
for  the  project  management  team  to  be  familiar  with  a variety  of  sampling  techniques  to  assure  the  sample  selected 
represents  the  population  of  interest. 

8.1 .2.7  Additional  Quality  Planning  Tools 

Other  quality  planning  tools  are  used  to  define  the  quality  requirements  and  to  plan  effective  quality  management 
activities.  These  include,  but  are  not  limited  to: 

• Brainstorming.  This  technique  is  used  to  generate  ideas  (defined  in  Section  1 1 .2.2.2). 

• Force  field  analysis.  These  are  diagrams  of  the  forces  for  and  against  change. 

• Nominal  group  technique.  This  technique  is  used  to  allow  ideas  to  be  brainstormed  in  small  groups  and 
then  reviewed  by  a larger  group. 

• Quality  management  and  control  tools.  These  tools  are  used  to  link  and  sequence  the  activities 
identified  (defined  in  Section  8. 2.2.1). 
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8.1 .2.8  Meetings 

Project  teams  may  hold  planning  meetings  to  develop  the  quality  management  plan.  Attendees  at  these 
meetings  may  include  the  project  manager;  the  project  sponsor;  selected  project  team  members;  selected 
stakeholders;  anyone  with  responsibility  for  Project  Quality  Management  activities  namely  Plan  Quality 
Management,  Perform  Quality  Assurance,  or  Control  Quality;  and  others  as  needed. 

8.1.3  Plan  Quality  Management:  Outputs 

8.1 .3.1  Quality  Management  Plan 

The  quality  management  plan  is  a component  of  the  project  management  plan  that  describes  how  the 
organization’s  quality  policies  will  be  implemented.  It  describes  how  the  project  management  team  plans  to  meet 
the  quality  requirements  set  for  the  project. 

The  quality  management  plan  may  be  formal  or  informal,  detailed,  or  broadly  framed.  The  style  and  detail  of  the 
quality  management  plan  are  determined  by  the  requirements  of  the  project.  The  quality  management  plan  should 
be  reviewed  early  in  the  project  to  ensure  that  decisions  are  based  on  accurate  information.  The  benefits  of  this 
review  can  include  a sharper  focus  on  the  project’s  value  proposition  and  reductions  in  costs  and  in  the  frequency 
of  schedule  overruns  that  were  caused  by  rework. 

8.1 .3.2  Process  Improvement  Plan 

The  process  improvement  plan  is  a subsidiary  or  component  of  the  project  management  plan  (Section  4. 2.3.1 ). 
The  process  improvement  plan  details  the  steps  for  analyzing  project  management  and  product  development 
processes  to  identify  activities  that  enhance  their  value.  Areas  to  consider  include: 

• Process  boundaries.  Describe  the  purpose  of  the  process,  the  start  and  end  of  the  process,  its  inputs 
and  outputs,  the  process  owner,  and  the  stakeholders  of  the  process. 

• Process  configuration.  Provides  a graphic  depiction  of  processes,  with  interfaces  identified,  used  to 
facilitate  analysis. 

• Process  metrics.  Along  with  control  limits,  allows  analysis  of  process  efficiency. 

• Targets  for  improved  performance.  Guide  the  process  improvement  activities. 
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8.1 .3.3  Quality  Metrics 

A quality  metric  specifically  describes  a project  or  product  attribute  and  how  the  control  quality  process  will 
measure  it.  A measurement  is  an  actual  value.  The  tolerance  defines  the  allowable  variations  to  the  metric.  For 
example,  if  the  quality  objective  is  to  stay  within  the  approved  budget  by  ± 10%,  the  specific  quality  metric  is 
used  to  measure  the  cost  of  every  deliverable  and  determine  the  percent  variance  from  the  approved  budget  for 
that  deliverable.  Quality  metrics  are  used  in  the  perform  quality  assurance  and  control  quality  processes.  Some 
examples  of  quality  metrics  include  on-time  performance,  cost  control,  defect  frequency,  failure  rate,  availability, 
reliability,  and  test  coverage. 

8.1 .3.4  Quality  Checklists 

A checklist  is  a structured  tool,  usually  component-specific,  used  to  verify  that  a set  of  required  steps  has 
been  performed.  Based  on  the  project’s  requirements  and  practices,  checklists  may  be  simple  or  complex.  Many 
organizations  have  standardized  checklists  available  to  ensure  consistency  in  frequently  performed  tasks.  In  some 
application  areas,  checklists  are  also  available  from  professional  associations  or  commercial  service  providers. 
Quality  checklists  should  incorporate  the  acceptance  criteria  included  in  the  scope  baseline. 

8.1 .3.5  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Stakeholder  register  (Section  13.1.3.1);  and 

• Responsibility  assignment  matrix  (Section  9.1 .2.1);  and 

• WBS  and  WBS  Dictionary. 


8.2  Perform  Quality  Assurance 

Perform  Quality  Assurance  is  the  process  of  auditing  the  quality  requirements  and  the  results  from  quality 
control  measurements  to  ensure  that  appropriate  quality  standards  and  operational  definitions  are  used.  The  key 
benefit  of  this  process  is  that  it  facilitates  the  improvement  of  quality  processes.  The  inputs,  tools  and  techniques, 
and  outputs  of  this  process  are  depicted  in  Figure  8-8.  Figure  8-9  depicts  the  data  flow  diagram  of  the  process. 
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Figure  8-8.  Perform  Quality  Assurance:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  8-9.  Perform  Quality  Assurance  Data  Flow  Diagram 


The  quality  assurance  process  implements  a set  of  planned  and  systematic  acts  and  processes  defined 
within  the  project’s  quality  management  plan.  Quality  assurance  seeks  to  build  confidence  that  a future  output 
or  an  unfinished  output,  also  known  as  work  in  progress,  will  be  completed  in  a manner  that  meets  the  specified 
requirements  and  expectations.  Quality  assurance  contributes  to  the  state  of  being  certain  about  quality  by 
preventing  defects  through  the  planning  processes  or  by  inspecting  out  defects  during  the  work-in-progress 
stage  of  implementation.  Perform  Quality  Assurance  is  an  execution  process  that  uses  data  created  during  Plan 
Quality  Management  (Section  8.1)  and  Control  Quality  (Section  8.3)  processes. 
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In  project  management,  the  prevention  and  inspection  aspects  of  quality  assurance  should  have  a demonstrable 
influence  on  the  project.  Quality  assurance  work  will  fall  under  the  conformance  work  category  in  the  cost  of  quality 
framework. 

A quality  assurance  department,  or  similar  organization,  often  oversees  quality  assurance  activities.  Quality 
assurance  support,  regardless  of  the  unit’s  title,  may  be  provided  to  the  project  team,  the  management  of  the 
performing  organization,  the  customer  or  sponsor,  as  well  as  other  stakeholders  not  actively  involved  in  the  work 
of  the  project. 

Perform  Quality  Assurance  also  provides  an  umbrella  for  continuous  process  improvement,  which  is  an  iterative 
means  for  improving  the  quality  of  all  processes.  Continuous  process  improvement  reduces  waste  and  eliminates 
activities  that  do  not  add  value.  This  allows  processes  to  operate  at  increased  levels  of  efficiency  and  effectiveness. 

8.2.1  Perform  Quality  Assurance:  Inputs 

8.2.1 .1  Quality  Management  Plan 

Described  in  Section  8.1 .3.1.  The  quality  management  plan  describes  the  quality  assurance  and  continuous 
process  improvement  approaches  for  the  project. 

8.2.1 .2  Process  Improvement  Plan 

Described  in  Section  8. 1.3. 2.  The  project’s  quality  assurance  activities  should  be  supportive  of  and  consistent 
with  the  performing  organization’s  process  improvement  plans. 

8.2.1 .3  Quality  Metrics 

Described  in  Section  8. 1.3. 3.  The  quality  metrics  provide  the  attributes  that  should  be  measured  and  the 
allowable  variations. 

8.2.1 .4  Quality  Control  Measurements 

Described  in  Section  8.3. 3.1 . Quality  control  measurements  are  the  results  of  control  quality  activities.  They  are 
used  to  analyze  and  evaluate  the  quality  of  the  processes  of  the  project  against  the  standards  of  the  performing 
organization  or  the  requirements  specified.  Quality  control  measurements  can  also  compare  the  processes  used  to 
create  the  measurements,  and  validate  actual  measurements  to  determine  their  level  of  correctness. 
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8.2.1 .5  Project  Documents 

Project  documents  may  influence  quality  assurance  work  and  should  be  monitored  within  the  context  of  a 
system  for  configuration  management. 

8.2.2  Perform  Quality  Assurance:  Tools  and  Techniques 
8.2.2.1  Quality  Management  and  Control  Tools 

The  Perform  Quality  Assurance  process  uses  the  tools  and  techniques  of  the  Plan  Quality  Management  and 
Control  Quality  processes.  In  addition,  other  tools  that  are  available  include  (see  also  Figure  8-1 0): 

• Affinity  diagrams.  The  affinity  diagram  is  similar  to  mind-mapping  techniques  in  that  they  are  used 
to  generate  ideas  that  can  be  linked  to  form  organized  patterns  of  thought  about  a problem.  In  project 
management,  the  creation  of  the  WBS  may  be  enhanced  by  using  the  affinity  diagram  to  give  structure 
to  the  decomposition  of  scope. 

• Process  decision  program  charts  (PDPC).  Used  to  understand  a goal  in  relation  to  the  steps  for  getting 
to  the  goal.  The  PDPC  is  useful  as  a method  for  contingency  planning  because  it  aids  teams  in  anticipating 
intermediate  steps  that  could  derail  achievement  of  the  goal. 

• Interrelationship  digraphs.  An  adaptation  of  relationship  diagrams.  The  interrelationship  digraphs 
provide  a process  for  creative  problem  solving  in  moderately  complex  scenarios  that  possess  intertwined 
logical  relationships  for  up  to  50  relevant  items.  The  interrelationship  digraph  may  be  developed  from 
data  generated  in  other  tools  such  as  the  affinity  diagram,  the  tree  diagram,  or  the  fishbone  diagram. 

• Tree  diagrams.  Also  known  as  systematic  diagrams  and  may  be  used  to  represent  decomposition 
hierarchies  such  as  the  WBS,  RBS  (risk  breakdown  structure),  and  OBS  (organizational  breakdown 
structure).  In  project  management,  tree  diagrams  are  useful  in  visualizing  the  parent-to-child  relationships 
in  any  decomposition  hierarchy  that  uses  a systematic  set  of  rules  that  define  a nesting  relationship.  Tree 
diagrams  can  be  depicted  horizontally  (such  as  a risk  breakdown  structure)  or  vertically  (such  as  a team 
hierarchy  or  OBS).  Because  tree  diagrams  permit  the  creation  of  nested  branches  that  terminate  into  a 
single  decision  point,  they  are  useful  as  decision  trees  for  establishing  an  expected  value  for  a limited 
number  of  dependent  relationships  that  have  been  diagramed  systematically. 
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• Prioritization  matrices.  Identify  the  key  issues  and  the  suitable  alternatives  to  be  prioritized  as  a set  of 
decisions  for  implementation.  Criteria  are  prioritized  and  weighted  before  being  applied  to  all  available 
alternatives  to  obtain  a mathematical  score  that  ranks  the  options. 

• Activity  network  diagrams.  Previously  known  as  arrow  diagrams.  They  include  both  the  AOA  (Activity 
on  Arrow)  and,  most  commonly  used,  AON  (Activity  on  Node)  formats  of  a network  diagram.  Activity 
network  diagrams  are  used  with  project  scheduling  methodologies  such  as  program  evaluation  and 
review  technique  (PERT),  critical  path  method  (CPM),  and  precedence  diagramming  method  (PDM). 

• Matrix  diagrams.  A quality  management  and  control  tool  used  to  perform  data  analysis  within  the 
organizational  structure  created  in  the  matrix.  The  matrix  diagram  seeks  to  show  the  strength  of 
relationships  between  factors,  causes,  and  objectives  that  exist  between  the  rows  and  columns  that  form 
the  matrix. 


Figure  8-10.  Storyboard  Illustrating  the  Seven  Quality  Management  and  Control  Tools 
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8.2.2.2  Quality  Audits 

A quality  audit  is  a structured,  independent  process  to  determine  if  project  activities  comply  with  organizational 
and  project  policies,  processes,  and  procedures.  The  objectives  of  a quality  audit  may  include: 

• Identify  all  good  and  best  practices  being  implemented; 

• Identify  all  nonconformity,  gaps,  and  shortcomings; 

• Share  good  practices  introduced  or  implemented  in  similar  projects  in  the  organization  and/or  industry; 

• Proactively  offer  assistance  in  a positive  manner  to  improve  implementation  of  processes  to  help  the 
team  raise  productivity;  and 

• Highlight  contributions  of  each  audit  in  the  lessons  learned  repository  of  the  organization. 

The  subsequent  effort  to  correct  any  deficiencies  should  result  in  a reduced  cost  of  quality  and  an  increase  in 
sponsor  or  customer  acceptance  of  the  project’s  product.  Quality  audits  may  be  scheduled  or  random,  and  may  be 
conducted  by  internal  or  external  auditors. 

Quality  audits  can  confirm  the  implementation  of  approved  change  requests  including  updates,  corrective 
actions,  defect  repairs,  and  preventive  actions. 

8.2.2.3  Process  Analysis 

Process  analysis  follows  the  steps  outlined  in  the  process  improvement  plan  to  identify  needed  improvements. 
This  analysis  also  examines  problems  experienced,  constraints  experienced,  and  non-value-added  activities 
identified  during  process  operation.  Process  analysis  includes  root  cause  analysis — a specific  technique  used  to 
identify  a problem,  discover  the  underlying  causes  that  lead  to  it,  and  develop  preventive  actions. 

8.2.3  Perform  Quality  Assurance:  Outputs 
8.2.3.1  Change  Requests 

Change  requests  are  created  and  used  as  input  into  the  Perform  Integrated  Change  Control  process  (Section  4.5) 
to  allow  full  consideration  of  the  recommended  improvements.  Change  requests  are  used  to  take  corrective  action, 
preventive  action,  or  to  perform  defect  repair. 
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8.2.3.2  Project  Management  Plan  Updates 

Elements  of  the  project  management  plan  that  may  be  updated  include,  but  are  not  limited  to: 

• Quality  management  plan  (Section  8.1 .3.1 ), 

• Scope  management  plan  (Section  5.1 .3.1 ), 

• Schedule  management  plan  (Section  6.1 .3.1),  and 

• Cost  management  plan  (7.1 .3.1 ). 

8.2. 3.3  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Quality  audit  reports, 

• Training  plans,  and 

• Process  documentation. 

8.2.3.4  Organizational  Process  Assets  Updates 

Elements  of  the  organizational  process  assets  that  may  be  updated  include,  but  are  not  limited  to,  the 
organization’s  quality  standards  and  the  quality  management  system. 


8.3  Control  Quality 

Control  Quality  is  the  process  of  monitoring  and  recording  results  of  executing  the  quality  activities  to  assess 
performance  and  recommend  necessary  changes.  The  key  benefits  of  this  process  include:  (1)  identifying  the 
causes  of  poor  process  or  product  quality  and  recommending  and/or  taking  action  to  eliminate  them;  and  (2) 
validating  that  project  deliverables  and  work  meet  the  requirements  specified  by  key  stakeholders  necessary  for 
final  acceptance.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  8-1 1 . Figure 
8-1 2 depicts  the  data  flow  diagram  of  the  process. 
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Figure  8-11.  Control  Quality:  Inputs,  Tools  & Techniques,  and  Outputs 


Figure  8-12.  Control  Quality  Data  Flow  Diagram 
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The  Control  Quality  process  uses  a set  of  operational  techniques  and  tasks  to  verify  that  the  delivered  output 
will  meet  the  requirements.  Quality  assurance  should  be  used  during  the  project’s  planning  and  executing  phases 
to  provide  confidence  that  the  stakeholder’s  requirements  will  be  met  and  quality  control  should  be  used  during 
the  project  executing  and  closing  phases  to  formally  demonstrate,  with  reliable  data,  that  the  sponsor  and/or 
customer’s  acceptance  criteria  have  been  met. 

The  project  management  team  may  have  a working  knowledge  of  statistical  control  processes  to  evaluate  data 
contained  in  the  control  quality  outputs.  Among  other  subjects,  the  team  may  find  it  useful  to  know  the  differences 
between  the  following  pairs  of  terms: 

• Prevention  (keeping  errors  out  of  the  process)  and  inspection  (keeping  errors  out  of  the  hands  of  the 
customer). 

• Attribute  sampling  (the  result  either  conforms  or  does  not  conform)  and  variables  sampling  (the  result  is 
rated  on  a continuous  scale  that  measures  the  degree  of  conformity). 

• Tolerances  (specified  range  of  acceptable  results)  and  control  limits  (that  identify  the  boundaries  of 
common  variation  in  a statistically  stable  process  or  process  performance). 

8.3.1  Control  Quality:  Inputs 

8.3.1 .1  Project  Management  Plan 

Described  in  Section  8. 1.3.1.  The  project  management  plan  contains  the  quality  management  plan,  which  is 
used  to  control  quality.  The  quality  management  plan  describes  how  quality  control  will  be  performed  within  the 
project. 

8.3.1 .2  Quality  Metrics 

Described  in  Section  4. 2.3.1  .A  quality  metric  describes  a project  or  product  attribute  and  how  it  will  be  measured. 
Some  examples  of  quality  metrics  include:  function  points,  mean  time  between  failure  (MTBF),  and  mean  time  to 
repair  (MTTR). 

8.3.1 .3  Quality  Checklists 

Described  in  Section  8.1 .3.4.  Quality  checklists  are  structured  lists  that  help  to  verify  that  the  work  of  the  project 
and  its  deliverables  fulfill  a set  of  requirements. 
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8.3.1 .4  Work  Performance  Data 

Described  in  Section  4.3. 3.2.  Work  performance  data  can  include: 

• Planned  vs.  actual  technical  performance, 

• Planned  vs.  actual  schedule  performance,  and 

• Planned  vs.  actual  cost  performance. 

8.3.1 .5  Approved  Change  Requests 

As  part  of  the  Perform  Integrated  Change  Control  process,  a change  log  update  indicates  that  some  changes  are 
approved  and  some  are  not.  Approved  change  requests  may  include  modifications  such  as  defect  repairs,  revised 
work  methods,  and  revised  schedule.  The  timely  implementation  of  approved  changes  needs  to  be  verified. 

8.3.1 .6  Deliverables 

Described  in  Section  4.3. 3.1.  A deliverable  is  any  unique  and  verifiable  product,  result,  or  capability  that  results 
in  a validated  deliverable  required  by  the  project. 

8.3.1 .7  Project  Documents 

Project  documents  may  include,  but  are  not  limited  to: 

• Agreements, 

• Quality  audit  reports  and  change  logs  supported  with  corrective  action  plans, 

• Training  plans  and  assessments  of  effectiveness,  and 

• Process  documentation  such  as  those  obtained  using  either  the  seven  basic  quality  tools  or  the  quality 
management  and  control  tools  shown  in  Figures  8-7  and  8-10. 

8.3.1 .8  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  influence  the  Control  Quality  process  include, 
but  are  not  limited  to: 

• The  organization’s  quality  standards  and  policies, 

• Standard  work  guidelines,  and 

• Issue  and  defect  reporting  procedures  and  communication  policies. 
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8.3.2  Control  Quality:  Tools  and  Techniques 

8.3.2.1  Seven  Basic  Quality  Tools 

Described  in  Section  8.1 .2.3.  The  seven  basic  quality  tools  are  illustrated  conceptually  in  Figure  8-7. 

8.3.2.2  Statistical  Sampling 

Described  in  Section  8.1 .2.6.  Samples  are  selected  and  tested  as  defined  in  the  quality  management  plan. 

8.3.2.3  Inspection 

An  inspection  is  the  examination  of  a work  product  to  determine  if  it  conforms  to  documented  standards.  The 
results  of  an  inspection  generally  include  measurements  and  may  be  conducted  at  any  level.  For  example,  the 
results  of  a single  activity  can  be  inspected,  or  the  final  product  of  the  project  can  be  inspected.  Inspections  may 
be  called  reviews,  peer  reviews,  audits,  or  walkthroughs.  In  some  application  areas,  these  terms  have  narrow  and 
specific  meanings.  Inspections  also  are  used  to  validate  defect  repairs. 

8.3.2.4  Approved  Change  Requests  Review 

All  approved  change  requests  should  be  reviewed  to  verify  that  they  were  implemented  as  approved. 

8.3.3  Control  Quality:  Outputs 

8.3.3.1  Quality  Control  Measurements 

Quality  control  measurements  are  the  documented  results  of  control  quality  activities.  They  should  be  captured 
in  the  format  that  was  specified  through  the  Plan  Quality  Management  process  (Section  8.1). 

8.3.3.2  Validated  Changes 

Any  changed  or  repaired  items  are  inspected  and  will  be  either  accepted  or  rejected  before  notification  of  the 
decision  is  provided.  Rejected  items  may  require  rework. 
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8.3.3.3  Verified  Deliverables 

A goal  of  the  Control  Quality  process  is  to  determine  the  correctness  of  deliverables.  The  results  of  performing 
the  Control  Quality  process  are  verified  deliverables.  Verified  deliverables  are  an  input  to  Validate  Scope  (5.5. 1.4) 
for  formalized  acceptance. 

8.3.3.4  Work  Performance  Information 

Work  performance  information  is  the  performance  data  collected  from  various  controlling  processes,  analyzed 
in  context  and  integrated  based  on  relationships  across  areas.  Examples  include  information  about  the  project 
requirements  fulfillment  such  as  causes  for  rejections,  rework  required,  or  the  need  for  process  adjustments. 

8.3.3.5  Change  Requests 

If  the  recommended  corrective  or  preventive  actions  or  a defect  repair  requires  a change  to  the  project 
management  plan,  a change  request  (Section  4.4. 3.1)  should  be  initiated  in  accordance  with  the  defined  Perform 
Integrated  Change  Control  (4.5)  process. 

8.3.3.6  Project  Management  Plan  Updates 

Elements  of  the  project  management  plan  that  may  be  updated  include,  but  are  not  limited  to: 

• Quality  management  plan  (Section  8.1 .3.1 ),  and 

• Process  improvement  plan  (Section  8.1 .3.2). 

8.3.3.7  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to, 

• Quality  standards; 

• Agreements; 

• Quality  audit  reports  and  change  logs  supported  with  corrective  action  plans; 

• Training  plans  and  assessments  of  effectiveness;  and 

• Process  documentation,  such  as  information  obtained  using  the  seven  basic  quality  tools  or  the  quality 
management  and  control  tools. 
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8.3.3.8  Organizational  Process  Assets  Updates 

Elements  of  the  organizational  process  assets  that  may  be  updated  include,  but  are  not  limited  to: 

• Completed  checklists.  When  checklists  are  used,  the  completed  checklists  become  part  of  the  project 
documents  and  organizational  process  assets  (Section  4.1.1 .5). 

• Lessons  learned  documentation.  The  causes  of  variances,  the  reasoning  behind  the  corrective  action 
chosen,  and  other  types  of  lessons  learned  from  control  quality  are  documented  so  they  become  part  of 
the  historical  database  for  both  the  project  and  the  performing  organization. 
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PROJECT  HUMAN  RESOURCE  MANAGEMENT 


Project  Human  Resource  Management  includes  the  processes  that  organize,  manage,  and  lead  the  project 
team.  The  project  team  is  comprised  of  the  people  with  assigned  roles  and  responsibilities  for  completing  the 
project.  Project  team  members  may  have  varied  skill  sets,  may  be  assigned  full  or  part-time,  and  may  be  added  or 
removed  from  the  team  as  the  project  progresses.  Project  team  members  may  also  be  referred  to  as  the  project’s 
staff.  Although  specific  roles  and  responsibilities  for  the  project  team  members  are  assigned,  the  involvement  of 
all  team  members  in  project  planning  and  decision  making  is  beneficial.  Participation  of  team  members  during 
planning  adds  their  expertise  to  the  process  and  strengthens  their  commitment  to  the  project. 

Figure  9-1  provides  an  overview  of  the  Project  Human  Resource  Management  processes,  which  are  as  follows: 

9.1  Plan  Human  Resource  Management — The  process  of  identifying  and  documenting  project  roles, 
responsibilities,  required  skills,  reporting  relationships,  and  creating  a staffing  management  plan. 

9.2  Acquire  Project  Team — The  process  of  confirming  human  resource  availability  and  obtaining  the 
team  necessary  to  complete  project  activities. 

9.3  Develop  Project  Team — The  process  of  improving  competencies,  team  member  interaction,  and 
overall  team  environment  to  enhance  project  performance. 

9.4  Manage  Project  Team — The  process  of  tracking  team  member  performance,  providing  feedback, 
resolving  issues,  and  managing  changes  to  optimize  project  performance. 
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These  processes  interact  with  each  other  and  with  processes  in  other  Knowledge  Areas  as  described  in  detail 
in  Section  3 and  Annex  A1. 

As  a result  of  these  interactions  additional  planning  may  be  required  throughout  the  project.  For  example: 

• After  initial  team  members  create  a work  breakdown  structure,  additional  team  members  may  need  to 
be  added  to  the  team. 

• As  additional  team  members  are  added  to  the  team,  their  experience  levels,  or  lack  thereof,  could 
decrease  or  increase  project  risk,  creating  the  need  for  additional  risk  planning. 

• When  activity  durations  are  estimated,  budgeted,  scoped,  or  planned  prior  to  identifying  all  project  team 
members  and  their  competency  levels,  the  activity  durations  may  change. 

The  project  management  team  is  a subset  of  the  project  team  and  is  responsible  for  the  project  management 
and  leadership  activities  such  as  initiating,  planning,  executing,  monitoring,  controlling,  and  closing  the  various 
project  phases.  This  group  can  also  be  referred  to  as  the  core,  executive,  or  leadership  team.  For  smaller  projects, 
the  project  management  responsibilities  may  be  shared  by  the  entire  team  or  administered  solely  by  the  project 
manager.  The  project  sponsor  works  with  the  project  management  team,  typically  assisting  with  matters  such  as 
project  funding,  clarifying  scope,  monitoring  progress,  and  influencing  stakeholders  in  both  the  requesting  and 
performing  organization  for  the  project  benefit. 

Managing  and  leading  the  project  team  includes,  but  is  not  limited  to: 

• Influencing  the  project  team.  The  project  manager  needs  to  be  aware  of  and  influence,  when  possible, 
human  resource  factors  that  may  impact  the  project.  These  factors  includes  team  environment, 
geographical  locations  of  team  members,  communications  among  stakeholders,  internal  and  external 
politics,  cultural  issues,  organizational  uniqueness,  and  others  factors  that  may  alter  project  performance. 

• Professional  and  ethical  behavior.  The  project  management  team  should  be  aware  of,  subscribe  to,  and 
ensure  that  all  team  members  follow  professional  and  ethical  behavior. 
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Figure  9-1 . Project  Human  Resource  Management  Overview 
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9.1  Plan  Human  Resource  Management 

Plan  Human  Resource  Management  is  the  process  of  identifying  and  documenting  project  roles,  responsibilities, 
required  skills,  reporting  relationships,  and  creating  a staffing  management  plan.  The  key  benefit  of  this  process 
is  that  it  establishes  project  roles  and  responsibilities,  project  organization  charts,  and  the  staffing  management 
plan  including  the  timetable  for  staff  acquisition  and  release.  The  inputs,  tools  and  techniques,  and  outputs  of  this 
process  are  depicted  in  Figure  9-2.  Figure  9-3  depicts  the  data  flow  diagram  of  the  process. 
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Figure  9-2.  Plan  Human  Resource  Management:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  9-3.  Plan  Human  Resource  Management  Data  Flow  Diagram 
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Human  resource  planning  is  used  to  determine  and  identify  human  resources  with  the  necessary  skills  required 
for  project  success.  The  human  resource  management  plan  describes  how  the  roles  and  responsibilities,  reporting 
relationships,  and  staffing  management  will  be  addressed  and  structured  within  a project.  It  also  contains  the 
staffing  management  plan  including  timetables  for  staff  acquisition  and  release,  identification  of  training  needs, 
team-building  strategies,  plans  for  recognition  and  rewards  programs,  compliance  considerations,  safety  issues, 
and  the  impact  of  the  staffing  management  plan  on  the  organization. 

Effective  human  resource  planning  should  consider  and  plan  for  the  availability  of  or  competition  for  scarce 
resources.  Project  roles  can  be  designated  for  teams  or  team  members.  Those  teams  or  team  members  can 
be  from  inside  or  outside  the  organization  performing  the  project.  Other  projects  may  be  competing  for  human 
resources  with  the  same  competencies  or  skill  sets.  Given  these  factors,  project  costs,  schedules,  risks,  quality,  and 
other  project  areas  may  be  significantly  affected. 

9.1.1  Plan  Human  Resource  Management:  Inputs 

9.1 .1.1  Project  Management  Plan 

Described  in  Section  4.2. 3.1  .The  project  management  plan  is  used  to  develop  the  human  resource  management 
plan  as  described  in  Section  9.1 .3.1 . The  information  used  for  the  development  of  the  human  resource  management 
plan  includes,  but  is  not  limited  to: 

• The  project  life  cycle  and  the  processes  that  will  be  applied  to  each  phase, 

• How  work  will  be  executed  to  accomplish  the  project  objectives, 

• A change  management  plan  that  documents  how  changes  will  be  monitored  and  controlled, 

• A configuration  management  plan  that  documents  how  configuration  management  will  be  performed, 

• How  integrity  of  the  project  baselines  will  be  maintained,  and 

• Needs  and  methods  of  communication  among  stakeholders. 
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9.1 .1 .2  Activity  Resource  Requirements 

Described  in  Section  6. 4.3.1.  Human  resource  planning  uses  activity  resource  requirements  to  determine  the 
human  resource  needs  for  the  project.  The  preliminary  requirements  regarding  the  required  project  team  members 
and  their  competencies  are  progressively  elaborated  as  part  of  the  Plan  Human  Resource  Management  process. 

9.1 .1 .3  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  The  enterprise  environmental  factors  that  can  influence  the  Plan  Human  Resource 
Management  process  include,  but  are  not  limited  to: 

• Organizational  culture  and  structure, 

• Existing  human  resources, 

• Geographical  dispersion  of  team  members, 

• Personnel  administration  policies,  and 

• Marketplace  conditions. 

9.1 .1 .4  Organizational  Process  Assets 

Described  in  Section  2.1.4.  The  organizational  process  assets  that  can  influence  the  Plan  Human  Resource 
Management  process  include,  but  are  not  limited  to: 

• Organizational  standard  processes,  policies,  and  role  descriptions; 

• Templates  for  organizational  charts  and  position  descriptions; 

• Lessons  learned  on  organizational  structures  that  have  worked  in  previous  projects;  and 

• Escalation  procedures  for  handling  issues  within  the  team  and  within  the  performing  organization. 
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9.1.2  Plan  Human  Resource  Management:  Tools  and  Techniques 

9.1 .2.1  Organization  Charts  and  Position  Descriptions 

Various  formats  exist  to  document  team  member  roles  and  responsibilities.  Most  of  the  formats  fall  into  one  of 
three  types  (Figure  9-4):  hierarchical,  matrix,  and  text-oriented.  Additionally,  some  project  assignments  are  listed 
in  subsidiary  plans,  such  as  the  risk,  quality,  or  communications  management  plans.  Regardless  of  the  method 
utilized,  the  objective  is  to  ensure  that  each  work  package  has  an  unambiguous  owner  and  that  all  team  members 
have  a clear  understanding  of  their  roles  and  responsibilities.  For  example,  a hierarchical  format  may  be  used  to 
represent  high-level  roles,  while  a text-based  format  may  be  better  suited  to  document  the  detailed  responsibilities. 


Organization  Chart 
(hierarchical) 


Responsibility  Chart 
(matrix) 


Role  Description 
(text) 


Figure  9-4.  Roles  and  Responsibility  Definition  Formats 


• Hierarchical-type  charts.  The  traditional  organization  chart  structure  can  be  used  to  show  positions  and 
relationships  in  a graphical,  top-down  format.  Work  breakdown  structures  (WBS)  designed  to  show  how 
project  deliverables  are  broken  down  into  work  packages  provide  a way  of  showing  high-level  areas  of 
responsibility.  While  the  WBS  shows  a breakdown  of  project  deliverables,  the  organizational  breakdown 
structure  (OBS)  is  arranged  according  to  an  organization’s  existing  departments,  units,  or  teams  with  the 
project  activities  or  work  packages  listed  under  each  department.  An  operational  department  such  as 
information  technology  or  purchasing  can  see  all  of  its  project  responsibilities  by  looking  at  its  portion  of 
the  OBS.  The  resource  breakdown  structure  (RBS)  is  a hierarchical  list  of  resources  related  by  category 
and  resource  type  that  is  used  to  facilitate  planning  and  controlling  of  project  work.  Each  descending 
(lower)  level  represents  an  increasingly  detailed  description  of  the  resource  until  small  enough  to  be  used 
in  conjunction  with  the  work  breakdown  structure  (WBS)  to  allow  the  work  to  be  planned,  monitored  and 
controlled.  The  resource  breakdown  structure  is  helpful  in  tracking  project  costs  and  can  be  aligned  with 
the  organization’s  accounting  system.  It  can  contain  resource  categories  other  than  human  resources. 
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• Matrix-based  charts.  A responsibility  assignment  matrix  (RAM)  is  a grid  that  shows  the  project 
resources  assigned  to  each  work  package.  It  is  used  to  illustrate  the  connections  between  work 
packages  or  activities  and  project  team  members.  On  larger  projects,  RAMs  can  be  developed 
at  various  levels.  For  example,  a high-level  RAM  can  define  what  a project  team  group  or  unit  is 
responsible  for  within  each  component  of  the  WBS,  while  lower-level  RAMs  are  used  within  the  group 
to  designate  roles,  responsibilities,  and  levels  of  authority  for  specific  activities.  The  matrix  format 
shows  all  activities  associated  with  one  person  and  all  people  associated  with  one  activity.  This  also 
ensures  that  there  is  only  one  person  accountable  for  any  one  task  to  avoid  confusion  of  responsibility. 
One  example  of  a RAM  is  a RACI  (responsible,  accountable,  consult,  and  inform)  chart,  shown  in 
Figure  9-5.  The  sample  chart  shows  the  work  to  be  done  in  the  left  column  as  activities.  The  assigned 
resources  can  be  shown  as  individuals  or  groups.  The  project  manager  can  select  other  options  such 
as  “lead”  and  “resource”  designations  or  others,  as  appropriate  for  the  project.  A RACI  chart  is  a useful 
tool  to  use  when  the  team  consists  of  internal  and  external  resources  in  order  to  ensure  clear  divisions 
of  roles  and  expectations. 
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Figure  9-5.  RACI  Matrix 

• Text-oriented  formats.  Team  member  responsibilities  that  require  detailed  descriptions  can  be 
specified  in  text-oriented  formats.  Usually  in  outline  form,  the  documents  provide  information  such  as 
responsibilities,  authority,  competencies,  and  qualifications.  The  documents  are  known  by  various  names 
including  position  descriptions  and  role-responsibility-authority  forms.  These  documents  can  be  used  as 
templates  for  future  projects,  especially  when  the  information  is  updated  throughout  the  current  project 
by  applying  lessons  learned. 
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9.1 .2.2  Networking 

Networking  is  the  formal  and  informal  interaction  with  others  in  an  organization,  industry,  or  professional 
environment.  It  is  a constructive  way  to  understand  political  and  interpersonal  factors  that  will  impact  the 
effectiveness  of  various  staffing  management  options.  Human  resource  management  benefits  from  successful 
networking  by  improving  knowledge  of  and  access  to  human  resource  assets  such  as  strong  competencies, 
specialized  experience,  and  external  partnership  opportunities.  Examples  of  human  resources  networking  activities 
include  proactive  correspondence,  luncheon  meetings,  informal  conversations  including  meetings  and  events, 
trade  conferences,  and  symposia.  Networking  can  be  a useful  technique  at  the  beginning  of  a project.  It  can  also 
be  an  effective  way  to  enhance  project  management  professional  development  during  the  project  and  after  the 
project  ends. 

9.1 .2.3  Organizational  Theory 

Organizational  theory  provides  information  regarding  the  way  in  which  people,  teams,  and  organizational 
units  behave.  Effective  use  of  common  themes  identified  in  organizational  theory  can  shorten  the  amount  of  time, 
cost,  and  effort  needed  to  create  the  Plan  Human  Resource  Management  process  outputs  and  improve  planning 
efficiency.  It  is  important  to  recognize  that  different  organizational  structures  have  different  individual  response, 
individual  performance,  and  personal  relationship  characteristics.  Also,  applicable  organizational  theories  may 
recommend  exercising  a flexible  leadership  style  that  adapts  to  the  changes  in  a team’s  maturity  level  throughout 
the  project  life  cycle. 

9.1 .2.4  Expert  Judgment 

When  developing  the  human  resource  management  plan,  expert  judgment  is  used  to: 

• List  the  preliminary  requirements  for  the  required  skills; 

• Assess  the  roles  required  for  the  project  based  on  standardized  role  descriptions  within  the  organization; 

• Determine  the  preliminary  effort  level  and  number  of  resources  needed  to  meet  project  objectives; 

• Determine  reporting  relationships  needed  based  on  the  organizational  culture; 

• Provide  guidelines  on  lead  time  required  for  staffing,  based  on  lessons  learned  and  market  conditions; 

• Identify  risks  associated  with  staff  acquisition,  retention,  and  release  plans;  and 

• Identify  and  recommend  programs  for  complying  with  applicable  government  and  union  contracts. 
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9.1 .2.5  Meetings 

When  planning  human  resource  management  of  the  project,  the  project  management  team  will  hold  planning 
meetings.  These  meetings  leverage  a combination  of  other  tools  and  techniques  to  allow  for  all  project  management 
team  members  to  reach  consensus  on  the  human  resource  management  plan. 

9.1.3  Plan  Human  Resource  Management:  Outputs 
9.1 .3.1  Human  Resource  Management  Plan 

The  human  resource  management  plan,  a part  of  the  project  management  plan,  provides  guidance  on  how 
project  human  resources  should  be  defined,  staffed,  managed,  and  eventually  released.  The  human  resource 
management  plan  and  any  subsequent  revisions  are  also  inputs  into  the  Develop  Project  Management  Plan  process. 

The  human  resource  management  plan  includes,  but  is  not  limited  to,  the  following: 

• Roles  and  responsibilities.  The  following  should  be  addressed  when  listing  the  roles  and  responsibilities 
needed  to  complete  a project: 

o Role.  The  function  assumed  by  or  assigned  to  a person  in  the  project.  Examples  of  project  roles 
are  civil  engineer,  business  analyst,  and  testing  coordinator.  Role  clarity  concerning  authority, 
responsibilities,  and  boundaries  should  also  be  documented. 

o Authority.  The  right  to  apply  project  resources,  make  decisions,  sign  approvals,  accept 
deliverables,  and  influence  others  to  carry  out  the  work  of  the  project.  Examples  of  decisions 
that  need  clear  authority  include  the  selection  of  a method  for  completing  an  activity,  quality 
acceptance,  and  how  to  respond  to  project  variances.  Team  members  operate  best  when  their 
individual  levels  of  authority  match  their  individual  responsibilities. 

o Responsibility.  The  assigned  duties  and  work  that  a project  team  member  is  expected  to  perform 
in  order  to  complete  the  project’s  activities. 

o Competency.  The  skill  and  capacity  required  to  complete  assigned  activities  within  the  project 
constraints.  If  project  team  members  do  not  possess  required  competencies,  performance  can 
be  jeopardized.  When  such  mismatches  are  identified,  proactive  responses  such  as  training, 
hiring,  schedule  changes,  or  scope  changes  are  initiated. 
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• Project  organization  charts.  A project  organization  chart  is  a graphic  display  of  project  team  members 
and  their  reporting  relationships.  It  can  be  formal  or  informal,  highly  detailed  or  broadly  framed,  based  on 
the  needs  of  the  project.  For  example,  the  project  organization  chart  for  a 3,000-person  disaster  response 
team  will  have  greater  detail  than  a project  organization  chart  for  an  internal,  twenty-person  project. 

• Staffing  management  plan.  The  staffing  management  plan  is  a component  of  the  human  resource 
management  plan  that  describes  when  and  how  project  team  members  will  be  acquired  and  how  long 
they  will  be  needed.  It  describes  how  human  resource  requirements  will  be  met.  The  staffing  management 
plan  can  be  formal  or  informal,  highly  detailed,  or  broadly  framed,  depending  upon  the  needs  of  the 
project.  The  plan  is  updated  continually  during  the  project  to  direct  ongoing  team  member  acquisition  and 
development  actions.  Information  in  the  staffing  management  plan  varies  by  application  area  and  project 
size,  but  items  to  consider  include: 

o Staff  acquisition.  A number  of  questions  arise  when  planning  the  acquisition  of  project  team 
members.  For  example,  whether  the  human  resources  come  from  within  the  organization  or 
from  external,  contracted  sources;  whether  the  team  members  need  to  work  in  a central  location 
or  may  work  from  distant  locations;  costs  associated  with  each  level  of  expertise  needed  for 
the  project;  and  level  of  assistance  that  the  organization’s  human  resource  department  and 
functional  managers  are  able  to  provide  to  the  project  management  team. 

o Resource  calendars.  Calendars  that  identify  the  working  days  and  shifts  on  which  each  specific 
resource  is  available.  The  staffing  management  plan  describes  necessary  time  frames  for 
project  team  members,  either  individually  or  collectively,  as  well  as  when  acquisition  activities 
such  as  recruiting  should  start.  One  tool  for  charting  human  resources  is  a resource  histogram, 
used  by  the  project  management  team  as  a means  of  providing  a visual  representation  or 
resources  allocation  to  all  interested  parties.  This  chart  illustrates  the  number  of  hours  a person, 
department,  or  entire  project  team  that  will  be  needed  each  week  or  month  over  the  course 
of  the  project.  The  chart  can  include  a horizontal  line  that  represents  the  maximum  number  of 
hours  available  from  a particular  resource.  Bars  that  extend  beyond  the  maximum  available 
hours  identify  the  need  for  a resource  optimization  strategy  (Section  6.6. 2.4),  such  as  adding 
more  resources  or  modifying  the  schedule.  An  example  of  a resource  histogram  is  illustrated  in 
Figure  9-6. 
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Figure  9-6.  Illustrative  Resource  Histogram 

o Staff  release  plan.  Determining  the  method  and  timing  of  releasing  team  members  benefits  both 
the  project  and  team  members.  When  team  members  are  released  from  a project,  the  costs 
associated  with  those  resources  are  no  longer  charged  to  the  project,  thus  reducing  project 
costs.  Morale  is  improved  when  smooth  transitions  to  upcoming  projects  are  already  planned.  A 
staff  release  plan  also  helps  mitigate  human  resource  risks  that  may  occur  during  or  at  the  end 
of  a project. 

o Training  needs.  If  it  is  expected  that  the  team  members  to  be  assigned  will  not  have  the  required 
competencies,  a training  plan  can  be  developed  as  part  of  the  project.  The  plan  can  also  include 
ways  to  help  team  members  obtain  certifications  that  would  support  their  ability  to  benefit  the 
project. 

o Recognition  and  rewards.  Clear  criteria  for  rewards  and  a planned  system  for  their  use  help 
promote  and  reinforce  desired  behaviors.  To  be  effective,  recognition  and  rewards  should  be 
based  on  activities  and  performance  under  a person’s  control.  For  example,  a team  member  who 
is  to  be  rewarded  for  meeting  cost  objectives  should  have  an  appropriate  level  of  control  over 
decisions  that  affect  expenses.  Creating  a plan  with  established  times  for  distribution  of  rewards 
ensures  that  recognition  takes  place  and  is  not  forgotten.  Recognition  and  rewards  are  part  of 
the  Develop  Project  Team  process  (Section  9.3). 
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o Compliance.  The  staffing  management  plan  can  include  strategies  for  complying  with  applicable 
government  regulations,  union  contracts,  and  other  established  human  resource  policies. 

o Safety.  Policies  and  procedures  that  protect  team  members  from  safety  hazards  can  be  included 
in  the  staffing  management  plan  as  well  as  in  the  risk  register. 

9.2  Acquire  Project  Team 

Acquire  Project  Team  is  the  process  of  confirming  human  resource  availability  and  obtaining  the  team  necessary 
to  complete  project  activities.  The  key  benefit  of  this  process  consists  of  outlining  and  guiding  the  team  selection 
and  responsibility  assignment  to  obtain  a successful  team.  The  inputs,  tools  and  techniques,  and  outputs  of  this 
process  are  depicted  in  Figure  9-7.  Figure  9-8  depicts  the  dataflow  diagram  of  the  process. 
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Figure  9-7.  Acquire  Project  Team:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  9-8.  Acquire  Project  Team  Data  Flow  Diagram 


The  project  management  team  may  or  may  not  have  direct  control  over  team  member  selection  because  of 
collective  bargaining  agreements,  use  of  subcontractor  personnel,  matrix  project  environment,  internal  or  external 
reporting  relationships,  or  other  various  reasons.  It  is  important  that  the  following  factors  are  considered  during  the 
process  of  acquiring  the  project  team: 

• The  project  manager  or  project  management  team  should  effectively  negotiate  and  influence  others  who 
are  in  a position  to  provide  the  required  human  resources  for  the  project. 

• Failure  to  acquire  the  necessary  human  resources  for  the  project  may  affect  project  schedules,  budgets, 
customer  satisfaction,  quality,  and  risks.  Insufficient  human  resources  or  capabilities  decrease  the 
probability  of  success  and,  in  a worst  case  scenario,  could  result  in  project  cancellation. 

• If  the  human  resources  are  not  available  due  to  constraints,  such  as  economic  factors  or  previous 
assignments  to  other  projects,  the  project  manager  or  project  team  may  be  required  to  assign  alternative 
resources,  perhaps  with  lower  competencies,  provided  there  is  no  violation  of  legal,  regulatory,  mandatory, 
or  other  specific  criteria. 
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These  factors  should  be  considered  and  planned  for  in  the  planning  stages  of  the  project.  The  project  manager  or 
project  management  team  will  be  required  to  reflect  the  impact  of  any  unavailability  of  required  human  resources  in 
the  project  schedule,  project  budget,  project  risks,  project  quality,  training  plans,  and  the  other  project  management 
plans. 


9.2.1  Acquire  Project  Team:  Inputs 

9.2.1 .1  Human  Resource  Management  Plan 

Described  in  Section  9.1 .3.1 . The  human  resource  management  plan  provides  guidance  on  how  project  human 
resources  should  be  identified,  staffed,  managed,  and  eventually  released.  It  includes: 

• Roles  and  responsibilities  defining  the  positions,  skills,  and  competencies  that  the  project  demands; 

• Project  organization  charts  indicating  the  number  of  people  needed  for  the  project;  and 

• Staffing  management  plan  delineating  the  time  periods  each  project  team  member  will  be  needed  and 
other  information  important  to  engage  the  project  team. 

9.2.1 .2  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  The  enterprise  environmental  factors  that  influence  the  Acquire  Project  Team  process 
include,  but  are  not  limited  to: 

• Existing  information  on  human  resources  including  availability,  competency  levels,  prior  experience, 
interest  in  working  on  the  project  and  their  cost  rate; 

• Personnel  administration  policies  such  as  those  that  affect  outsourcing; 

• Organizational  structure  as  described  in  Section  2.3.1 ; and 

• Colocation  or  multiple  locations. 

9.2.1 .3  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  influence  the  Acquire  Project  Team  process 
include,  but  are  not  limited  to,  organizational  standard  policies,  processes,  and  procedures. 
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9.2.2  Acquire  Project  Team:  Tools  and  Techniques 

9.2.2.1  Pre-assignment 

When  project  team  members  are  selected  in  advance,  they  are  considered  pre-assigned.  This  situation  can 
occur  if  the  project  is  the  result  of  specific  people  being  identified  as  part  of  a competitive  proposal,  if  the  project 
is  dependent  upon  the  expertise  of  particular  persons,  or  if  some  staff  assignments  are  defined  within  the  project 
charter. 

9.2.2.2  Negotiation 

Staff  assignments  are  negotiated  on  many  projects.  For  example,  the  project  management  team  may  need  to 
negotiate  with: 

• Functional  managers,  to  ensure  that  the  project  receives  appropriately  competent  staff  in  the  required 
time  frame  and  that  the  project  team  members  will  be  able,  willing,  and  authorized  to  work  on  the  project 
until  their  responsibilities  are  completed; 

• Other  project  management  teams  within  the  performing  organization,  to  appropriately  assign  scarce  or 
specialized  human  resources;  and 

• External  organizations,  vendors,  suppliers,  contractors,  etc.,  for  appropriate,  scarce,  specialized,  qualified, 
certified,  or  other  such  specified  human  resources.  Special  consideration  should  be  given  to  external 
negotiating  policies,  practices,  processes,  guidelines,  legal,  and  other  such  criteria. 

The  project  management  team’s  ability  to  influence  others  plays  an  important  role  in  negotiating  staff 
assignments,  as  do  the  politics  of  the  organizations  involved.  For  example,  a functional  manager  will  weigh  the 
benefits  and  visibility  of  competing  projects  when  determining  where  to  assign  exceptional  performers  requested 
by  various  project  teams. 

9.2.2.3  Acquisition 

When  the  performing  organization  is  unable  to  provide  the  staff  needed  to  complete  a project,  the  required 
services  may  be  acquired  from  outside  sources.  This  can  involve  hiring  individual  consultants  or  subcontracting 
work  to  another  organization. 
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9.2.2.4  Virtual  Teams 

The  use  of  virtual  teams  creates  new  possibilities  when  acquiring  project  team  members.  Virtual  teams  can  be 
defined  as  groups  of  people  with  a shared  goal  who  fulfill  their  roles  with  little  or  no  time  spent  meeting  face  to 
face.  The  availability  of  communication  technology  such  as  e-mail,  audio  conferencing,  social  media,  web-based 
meetings  and  video  conferencing  has  made  virtual  teams  feasible.  The  virtual  team  model  makes  it  possible  to: 

• Form  teams  of  people  from  the  same  organization  who  live  in  widespread  geographic  areas; 

• Add  special  expertise  to  a project  team  even  though  the  expert  is  not  in  the  same  geographic  area; 

• Incorporate  employees  who  work  from  home  offices; 

• Form  teams  of  people  who  work  different  shifts,  hours,  or  days; 

• Include  people  with  mobility  limitations  or  disabilities;  and 

• Move  forward  with  projects  that  would  have  been  ignored  due  to  travel  expenses. 

There  are  some  disadvantages  related  to  virtual  teams,  such  as  possibility  for  misunderstandings,  feeling 
of  isolation,  difficulties  in  sharing  knowledge  and  experience  between  team  members,  and  cost  of  appropriate 
technology.  Communication  planning  becomes  increasingly  important  in  a virtual  team  environment.  Additional 
time  may  be  needed  to  set  clear  expectations,  facilitate  communications,  develop  protocols  for  resolving  conflict, 
include  people  in  decision  making,  understand  cultural  differences,  and  share  credit  in  successes. 

9.2.2.5  Multi-Criteria  Decision  Analysis 

Selection  criteria  are  often  used  as  a part  of  acquiring  the  project  team.  By  use  of  a multi-criteria  decision 
analysis  tool,  criteria  are  developed  and  used  to  rate  or  score  potential  team  members.  The  criteria  are  weighted 
according  to  the  relative  importance  of  the  needs  within  the  team.  Some  examples  of  selection  criteria  that  can  be 
used  to  score  team  members  are  shown  as  follows: 

• Availability.  Identify  whether  the  team  member  is  available  to  work  on  the  project  within  the  time  period 
needed.  If  there  are  there  any  concerns  for  availability  during  the  project  timeline. 

• Cost.  Verify  if  the  cost  of  adding  the  team  member  is  within  the  prescribed  budget. 

• Experience.  Verify  that  the  team  member  has  the  relevant  experience  that  will  contribute  to  the  project 
success. 

• Ability.  Verify  that  the  team  member  has  the  competencies  needed  by  the  project. 
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• Knowledge.  Consider  if  the  team  member  has  relevant  knowledge  of  the  customer,  similar  implemented 
projects,  and  nuances  of  the  project  environment. 

• Skills.  Determine  whether  the  member  has  the  relevant  skills  to  use  a project  tool,  implementation,  or 
training. 

• Attitude.  Determine  whether  the  member  has  the  ability  to  work  with  others  as  a cohesive  team. 

• International  factors.  Consider  team  member  location,  time  zone  and  communication  capabilities. 

9.2.3  Acquire  Project  Team:  Outputs 

9.2.3.1  Project  Staff  Assignments 

The  project  is  staffed  when  appropriate  people  have  been  assigned  to  the  team.  The  documentation  of  these 
assignments  can  include  a project  team  directory,  memos  to  team  members,  and  names  inserted  into  other  parts 
of  the  project  management  plan,  such  as  project  organization  charts  and  schedules. 

9.2.3.2  Resource  Calendars 

Resource  calendars  document  the  time  periods  that  each  project  team  member  is  available  to  work  on  the  project. 
Creating  a reliable  schedule  (Section  6.6. 3.1 ) depends  on  having  a good  understanding  of  each  person’s  availability 
and  schedule  constraints,  including  time  zones,  work  hours,  vacation  time,  local  holidays,  and  commitments  to 
other  projects. 

9.2.3.3  Project  Management  Plan  Updates 

Elements  of  the  project  management  plan  that  may  be  updated  include,  but  are  not  limited  to,  the  human 
resource  management  plan.  For  example,  the  person  assigned  to  a predefined  role  may  not  fulfill  all  staffing 
requirements  outlined  in  the  human  resource  management  plan.  When  gaps  occur,  the  project  management  plan 
needs  to  be  updated  to  change  the  team  structure,  roles,  or  responsibilities. 
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9.3  Develop  Project  Team 

Develop  Project  Team  is  the  process  of  improving  competencies,  team  member  interaction,  and  overall  team 
environment  to  enhance  project  performance.  The  key  benefit  of  this  process  is  that  it  results  in  improved  teamwork, 
enhanced  people  skills  and  competencies,  motivated  employees,  reduced  staff  turnover  rates,  and  improved  overall 
project  performance.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  9-9. 
Figure  9-1 0 depicts  the  data  flow  diagram  of  the  process. 
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Figure  9-9.  Develop  Project  Team:  Inputs,  Tools  & Techniques,  and  Outputs 


Project  Human  Resource  Management 


Figure  9-10.  Develop  Project  Team  Data  Flow  Diagram 
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Project  managers  should  acquire  skills  to  identify,  build,  maintain,  motivate,  lead,  and  inspire  project  teams 
to  achieve  high  team  performance  and  to  meet  the  project’s  objectives.  Teamwork  is  a critical  factor  for  project 
success,  and  developing  effective  project  teams  is  one  of  the  primary  responsibilities  of  the  project  manager. 
Project  managers  should  create  an  environment  that  facilitates  teamwork.  Project  managers  should  continually 
motivate  their  team  by  providing  challenges  and  opportunities,  by  providing  timely  feedback  and  support  as 
needed,  and  by  recognizing  and  rewarding  good  performance.  High  team  performance  can  be  achieved  by  using 
open  and  effective  communication,  creating  team  building  opportunities,  developing  trust  among  team  members, 
managing  conflicts  in  a constructive  manner,  and  encouraging  collaborative  problem  solving  and  decision  making. 
The  project  manager  should  request  management  support  and/or  influence  the  appropriate  stakeholders  to  acquire 
the  resources  needed  to  develop  effective  project  teams. 

Project  managers  operate  in  a global  environment  and  work  on  projects  characterized  by  cultural  diversity.  Team 
members  often  have  diverse  industry  experience,  know  multiple  languages,  and  sometimes  operate  in  the  “team 
language”  that  may  be  a different  language  or  norm  than  their  native  one.  The  project  management  team  should 
capitalize  on  cultural  differences,  focus  on  developing  and  sustaining  the  project  team  throughout  the  project  life 
cycle,  and  promote  working  together  interdependently  in  a climate  of  mutual  trust.  Developing  the  project  team 
improves  the  people  skills,  technical  competencies,  and  overall  team  environment  and  project  performance.  It 
requires  clear,  timely,  effective,  and  efficient  communication  between  team  members  throughout  the  life  of  the 
project.  Objectives  of  developing  a project  team  include,  but  are  not  limited  to: 

• Improving  knowledge  and  skills  of  team  members  to  increase  their  ability  to  complete  project  deliverables, 
while  lowering  costs,  reducing  schedules,  and  improving  quality; 

• Improving  feelings  of  trust  and  agreement  among  team  members  to  raise  morale,  lower  conflict,  and 
increase  team  work;  and 

• Creating  a dynamic,  cohesive,  and  collaborative  team  culture  to  (1)  improve  individual  and  team 
productivity,  team  spirit,  and  cooperation  and  (2)  allow  cross  training  and  mentoring  between  team 
members  to  share  knowledge  and  expertise. 

9.3.1  Develop  Project  Team:  Inputs 

9.3.1 .1  Human  Resource  Management  Plan 

Described  in  Section  9.1 .3.1.  The  human  resource  management  plan  provides  guidance  on  how  project  human 
resources  should  be  defined,  staffed,  managed,  controlled,  and  eventually  released.  It  identifies  training  strategies 
and  plans  for  developing  the  project  team.  Items  such  as  rewards,  feedback,  additional  training,  and  disciplinary 
actions  can  be  added  to  the  plan  as  a result  of  ongoing  team  performance  assessments  and  other  forms  of  project 
team  management. 
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9.3.1 .2  Project  Staff  Assignments 

Described  in  Section  9. 2.3.1.  Team  development  starts  with  a list  of  the  project  team  members.  Project  staff 
assignment  documents  identify  the  people  who  are  on  the  team. 

9.3.1 .3  Resource  Calendars 

Described  in  Section  9. 2.3. 2.  Resource  calendars  identify  times  when  the  project  team  members  can  participate 
in  team  development  activities. 

9.3.2  Develop  Project  Team:  Tools  and  Techniques 

9.3.2.1  Interpersonal  Skills 

Interpersonal  skills,  sometimes  known  as  “soft  skills,”  are  behavioral  competencies  that  include  proficiencies 
such  as  communication  skills,  emotional  intelligence,  conflict  resolution,  negotiation,  influence,  team  building,  and 
group  facilitation.  These  soft  skills  are  valuable  assets  when  developing  the  project  team.  For  example,  the  project 
management  team  can  use  emotional  intelligence  to  reduce  tension  and  increase  cooperation  by  identifying, 
assessing,  and  controlling  the  sentiments  of  project  team  members,  anticipating  their  actions,  acknowledging  their 
concerns,  and  following  up  on  their  issues. 

9.3.2.2  Training 

Training  includes  all  activities  designed  to  enhance  the  competencies  of  the  project  team  members.  Training 
can  be  formal  or  informal.  Examples  of  training  methods  include  classroom,  online,  computer-based,  on-the-job 
training  from  another  project  team  member,  mentoring,  and  coaching.  If  project  team  members  lack  the  necessary 
management  or  technical  skills,  such  skills  can  be  developed  as  part  of  the  project  work.  Scheduled  training  takes 
place  as  stated  in  the  human  resource  management  plan.  Unplanned  training  takes  place  as  a result  of  observation, 
conversation,  and  project  performance  appraisals  conducted  during  the  controlling  process  of  managing  the  project 
team.  Training  costs  could  be  included  in  the  project  budget,  or  supported  by  performing  organization  if  the  added 
skills  may  be  useful  for  future  projects.  It  could  be  performed  by  in-house  or  external  trainers. 
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9.3.2.3  Team-Building  Activities 

Team-building  activities  can  vary  from  a 5-minute  agenda  item  in  a status  review  meeting  to  an  off-site, 
professionally  facilitated  experience  designed  to  improve  interpersonal  relationships.  The  objective  of  team-building 
activities  is  to  help  individual  team  members  work  together  effectively.  Team-building  strategies  are  particularly 
valuable  when  team  members  operate  from  remote  locations  without  the  benefit  of  face-to-face  contact.  Informal 
communication  and  activities  can  help  in  building  trust  and  establishing  good  working  relationships. 

As  an  ongoing  process,  team  building  is  crucial  to  project  success.  While  team  building  is  essential  during  the 
initial  stages  of  a project,  it  is  a never-ending  process.  Changes  in  a project  environment  are  inevitable,  and  to 
manage  them  effectively,  a continued  or  a renewed  team-building  effort  should  be  applied.  The  project  manager 
should  continually  monitor  team  functionality  and  performance  to  determine  if  any  actions  are  needed  to  prevent 
or  correct  various  team  problems. 

One  of  the  models  used  to  describe  team  development  is  the  Tuckman  ladder  (Tuckman,  1965;  Tuckman  & 
Jensen,  1977),  which  includes  five  stages  of  development  that  teams  may  go  through.  Although  it’s  common  for 
these  stages  to  occur  in  order,  it’s  not  uncommon  for  a team  to  get  stuck  in  a particular  stage  or  slip  to  an  earlier 
stage.  Projects  with  team  members  who  worked  together  in  the  past  may  skip  a stage. 

• Forming.  This  phase  is  where  the  team  meets  and  learns  about  the  project  and  their  formal  roles  and 
responsibilities.  Team  members  tend  to  be  independent  and  not  as  open  in  this  phase. 

• Storming.  During  this  phase,  the  team  begins  to  address  the  project  work,  technical  decisions,  and  the 
project  management  approach.  If  team  members  are  not  collaborative  and  open  to  differing  ideas  and 
perspectives,  the  environment  can  become  counterproductive. 

• Norming.  In  the  norming  phase,  team  members  begin  to  work  together  and  adjust  their  work  habits  and 
behaviors  to  support  the  team.  The  team  learns  to  trust  each  other. 

• Performing.  Teams  that  reach  the  performing  stage  function  as  a well-organized  unit.  They  are 
interdependent  and  work  through  issues  smoothly  and  effectively. 

• Adjourning.  In  the  adjourning  phase,  the  team  completes  the  work  and  moves  on  from  the  project. 
This  typically  occurs  when  staff  is  released  from  the  project  as  deliverables  are  completed  or  as  part  of 
carrying  out  the  Close  Project  or  Phase  process  (Section  4.6). 

The  duration  of  a particular  stage  depends  upon  team  dynamics,  team  size,  and  team  leadership.  Project 
managers  should  have  a good  understanding  of  team  dynamics  in  order  to  move  their  team  members  through  all 
stages  in  an  effective  manner. 
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9.3.2.4  Ground  Rules 

Ground  rules  establish  clear  expectations  regarding  acceptable  behavior  by  project  team  members.  Early 
commitment  to  clear  guidelines  decreases  misunderstandings  and  increases  productivity.  Discussing  ground  rules 
in  areas  such  as  code  of  conduct,  communication,  working  together,  or  meeting  etiquette  allows  team  members  to 
discover  values  that  are  important  to  one  another.  All  project  team  members  share  responsibility  for  enforcing  the 
rules  once  they  are  established. 

9.3.2.5  Colocation 

Colocation,  also  referred  to  as  “tight  matrix,”  involves  placing  many  or  all  of  the  most  active  project  team 
members  in  the  same  physical  location  to  enhance  their  ability  to  perform  as  a team.  Colocation  can  be  temporary, 
such  as  at  strategically  important  times  during  the  project,  or  for  the  entire  project.  Colocation  strategies  can 
include  a team  meeting  room  (sometimes  called  “war  room”),  places  to  post  schedules,  and  other  conveniences 
that  enhance  communication  and  a sense  of  community.  While  colocation  is  considered  a good  strategy,  the  use  of 
virtual  teams  can  bring  benefits  such  as  the  use  of  more  skilled  resources,  reduced  costs,  less  travel,  and  relocation 
expenses  and  the  proximity  of  team  members  to  suppliers,  customers,  or  other  key  stakeholders. 

9.3.2.6  Recognition  and  Rewards 

Part  of  the  team  development  process  involves  recognizing  and  rewarding  desirable  behavior.  The  original  plans 
concerning  ways  in  which  to  reward  people  are  developed  during  the  Plan  Human  Resource  Management  process. 
It  is  important  to  recognize  that  a particular  reward  given  to  any  individual  will  be  effective  only  if  it  satisfies  a 
need  which  is  valued  by  that  individual.  Award  decisions  are  made,  formally  or  informally,  during  the  process  of 
managing  the  project  team  through  project  performance  appraisals  (Section  9.4. 2.2).  Cultural  differences  should 
be  considered  when  determining  recognition  and  rewards. 

People  are  motivated  if  they  feel  they  are  valued  in  the  organization  and  this  value  is  demonstrated  by  the 
rewards  given  to  them.  Generally,  money  is  viewed  as  a tangible  aspect  of  any  reward  system,  but  intangible 
rewards  could  be  equally  or  even  more  effective.  Most  project  team  members  are  motivated  by  an  opportunity  to 
grow,  accomplish,  and  apply  their  professional  skills  to  meet  new  challenges.  A good  strategy  for  project  managers 
is  to  give  the  team  recognition  throughout  the  life  cycle  of  the  project  rather  than  waiting  until  the  project  is 
completed. 
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9.3.27  Personnel  Assessment  Tools 

Personnel  assessment  tools  give  the  project  manager  and  the  project  team  insight  into  areas  of  strength  and 
weakness.  These  tools  help  project  managers  assess  the  team  preferences,  aspirations,  how  they  process  and 
organize  information,  how  they  tend  to  make  decisions,  and  how  they  prefer  to  interact  with  people. 

Various  tools  are  available  such  as  attitudinal  surveys,  specific  assessments,  structured  interviews,  ability 
tests,  and  focus  groups.  These  tools  can  provide  improved  understanding,  trust,  commitment,  and  communications 
among  team  members  and  facilitate  more  productive  teams  throughout  the  project. 

9.3.3  Develop  Project  Team:  Outputs 
9.3.3.1  Team  Performance  Assessments 

As  project  team  development  efforts  such  as  training,  team  building,  and  colocation  are  implemented,  the 
project  management  team  makes  formal  or  informal  assessments  of  the  project  team’s  effectiveness.  Effective 
team  development  strategies  and  activities  are  expected  to  increase  the  team’s  performance,  which  increases 
the  likelihood  of  meeting  project  objectives.  Team  performance  assessment  criteria  should  be  determined  by  all 
appropriate  parties  and  incorporated  in  the  Develop  Project  Team  inputs. 

The  performance  of  a successful  team  is  measured  in  terms  of  technical  success  according  to  agreed-upon 
project  objectives  (including  quality  levels),  performance  on  project  schedule  (finished  on  time),  and  performance 
on  budget  (finished  within  financial  constraints).  High-performance  teams  are  characterized  by  these  task-oriented 
and  results-oriented  outcomes. 

The  evaluation  of  a team’s  effectiveness  may  include  indicators  such  as: 

• Improvements  in  skills  that  allow  individuals  to  perform  assignments  more  effectively, 

• Improvements  in  competencies  that  help  the  team  perform  better  as  a team, 

• Reduced  staff  turnover  rate,  and 

• Increased  team  cohesiveness  where  team  members  share  information  and  experiences  openly  and  help 
each  other  to  improve  the  overall  project  performance. 
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As  a result  of  conducting  an  evaluation  of  the  team’s  overall  performance,  the  project  management  team 
can  identify  the  specific  training,  coaching,  mentoring,  assistance,  or  changes  required  to  improve  the  team’s 
performance.  This  should  also  include  identification  of  the  appropriate  or  required  resources  necessary  to  achieve 
and  implement  the  improvements  identified  in  the  assessment.  These  resources  and  recommendations  for  team 
improvement  should  be  well  documented  and  forwarded  to  the  relevant  parties. 

9.3.3.2  Enterprise  Environmental  Factors  Updates 

The  enterprise  environmental  factors  that  may  be  updated  as  a result  of  the  Develop  Project  Team  process 
include,  but  are  not  limited  to,  personnel  administration,  employee  training  records,  and  skill  assessments. 


9.4  Manage  Project  Team 

Manage  Project  Team  is  the  process  of  tracking  team  member  performance,  providing  feedback,  resolving 
issues,  and  managing  team  changes  to  optimize  project  performance.  The  key  benefit  of  this  process  is  that  it 
influences  team  behavior,  manages  conflict,  resolves  issues,  and  appraises  team  member  performance.  The  inputs, 
tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  9-11.  Figure  9-12  depicts  the  data  flow 
diagram  of  the  process. 
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Figure  9-11.  Manage  Project  Team:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  9-12.  Manage  Project  Team  Data  Flow  Diagram 


As  a result  of  managing  the  project  team,  change  requests  are  submitted,  the  human  resource  management 
plan  is  updated,  issues  are  resolved,  input  is  provided  for  performance  appraisals,  and  lessons  learned  are  added 
to  the  organization’s  database. 

Managing  the  project  team  requires  a variety  of  management  skills  for  fostering  teamwork  and  integrating  the 
efforts  of  team  members  to  create  high-performance  teams.  Team  management  involves  a combination  of  skills 
with  special  emphasis  on  communication,  conflict  management,  negotiation,  and  leadership.  Project  managers 
should  provide  challenging  assignments  to  team  members  and  provide  recognition  for  high  performance. 
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9.4.1  Manage  Project  Team:  Inputs 

9.4.1 .1  Human  Resource  Management  Plan 

Described  in  Section  9.1 .3.1 . The  human  resource  management  plan  provides  guidance  on  how  project  human 
resources  should  be  defined,  staffed,  managed,  controlled,  and  eventually  released.  It  includes,  but  is  not  limited  to: 

• Roles  and  responsibilities, 

• Project  organization,  and 

• Staffing  management  plan. 

9.4.1 .2  Project  Staff  Assignments 

Described  in  Section  9. 2.3.1 . Project  staff  assignments  provide  documentation,  which  includes  the  list  of  project 
team  members. 

9.4.1 .3  Team  Performance  Assessments 

Described  in  Section  9.3. 3.1 . The  project  management  team  makes  ongoing  formal  or  informal  assessments  of 
the  project  team’s  performance.  By  continually  assessing  the  project  team’s  performance,  actions  can  be  taken  to 
resolve  issues,  modify  communication,  address  conflict,  and  improve  team  interaction. 

9.4.1 .4  Issue  Log 

Issues  arise  in  the  course  of  managing  the  project  team.  An  issue  log  can  be  used  to  document  and  monitor  who 
is  responsible  for  resolving  specific  issues  by  a target  date. 

9.4.1 .5  Work  Performance  Reports 

Described  in  Section  4. 4.3. 2.  Work  performance  reports  provide  documentation  about  the  current  project  status 
compared  to  project  forecasts.  Performance  areas  that  can  help  with  project  team  management  include  results 
from  schedule  control,  cost  control,  quality  control,  and  scope  validation.  The  information  from  performance  reports 
and  related  forecasts  assists  in  determining  future  human  resource  requirements,  recognition  and  rewards,  and 
updates  to  the  staffing  management  plan. 
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9.4.1 .6  Organizational  Process  Assets 

Described  in  Section  2.1.4.  The  organizational  process  assets  that  can  influence  the  Manage  Project  Team 
process  include,  but  are  not  limited  to: 

• Certificates  of  appreciation, 

• Newsletters, 

• Websites, 

• Bonus  structures, 

• Corporate  apparel,  and 

• Other  organizational  perquisites. 

9.4.2  Manage  Project  Team:  Tools  and  Techniques 

9.4.2.1  Observation  and  Conversation 

Observation  and  conversation  are  used  to  stay  in  touch  with  the  work  and  attitudes  of  project  team  members. 
The  project  management  team  monitors  progress  toward  project  deliverables,  accomplishments  that  are  a source 
of  pride  for  team  members,  and  interpersonal  issues. 

9.4.2.2  Project  Performance  Appraisals 

Objectives  for  conducting  performance  appraisals  during  the  course  of  a project  can  include  clarification  of 
roles  and  responsibilities,  constructive  feedback  to  team  members,  discovery  of  unknown  or  unresolved  issues, 
development  of  individual  training  plans,  and  the  establishment  of  specific  goals  for  future  time  periods. 

The  need  for  formal  or  informal  project  performance  appraisals  depends  on  the  length  of  the  project,  complexity  of 
the  project,  organizational  policy,  labor  contract  requirements,  and  the  amount  and  quality  of  regular  communication. 

9.4.2.3  Conflict  Management 

Conflict  is  inevitable  in  a project  environment.  Sources  of  conflict  include  scarce  resources,  scheduling 
priorities,  and  personal  work  styles.  Team  ground  rules,  group  norms,  and  solid  project  management  practices,  like 
communication  planning  and  role  definition,  reduce  the  amount  of  conflict. 
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Successful  conflict  management  results  in  greater  productivity  and  positive  working  relationships.  When 
managed  properly,  differences  of  opinion  can  lead  to  increased  creativity  and  better  decision  making.  If  the 
differences  become  a negative  factor,  project  team  members  are  initially  responsible  for  their  resolution.  If  conflict 
escalates,  the  project  manager  should  help  facilitate  a satisfactory  resolution.  Conflict  should  be  addressed  early 
and  usually  in  private,  using  a direct,  collaborative  approach.  If  disruptive  conflict  continues,  formal  procedures  may 
be  used,  including  disciplinary  actions. 

The  success  of  project  managers  in  managing  their  project  teams  often  depends  a great  deal  on  their  ability  to 
resolve  conflict.  Different  project  managers  may  utilize  different  conflict  resolution  methods.  Factors  that  influence 
conflict  resolution  methods  include: 

• Relative  importance  and  intensity  of  the  conflict, 

• Time  pressure  for  resolving  the  conflict, 

• Position  taken  by  persons  involved,  and 

• Motivation  to  resolve  conflict  on  a long-term  or  a short-term  basis. 

There  are  five  general  techniques  for  resolving  conflict.  As  each  one  has  its  place  and  use,  these  are  not  given 
in  any  particular  order: 

• Withdraw/Avoid.  Retreating  from  an  actual  or  potential  conflict  situation;  postponing  the  issue  to  be 
better  prepared  or  to  be  resolved  by  others. 

• Smooth/Accommodate.  Emphasizing  areas  of  agreement  rather  than  areas  of  difference;  conceding 
one’s  position  to  the  needs  of  others  to  maintain  harmony  and  relationships. 

• Compromise/Reconcile.  Searching  for  solutions  that  bring  some  degree  of  satisfaction  to  all  parties  in 
order  to  temporarily  or  partially  resolve  the  conflict. 

• Force/Direct.  Pushing  one’s  viewpoint  at  the  expense  of  others;  offering  only  win-lose  solutions,  usually 
enforced  through  a power  position  to  resolve  an  emergency. 

• Collaborate/Problem  Solve.  Incorporating  multiple  viewpoints  and  insights  from  differing  perspectives; 
requires  a cooperative  attitude  and  open  dialogue  that  typically  leads  to  consensus  and  commitment. 

g.4.2.4  Interpersonal  Skills 

Project  managers  use  a combination  of  technical,  personal,  and  conceptual  skills  to  analyze  situations  and 
interact  appropriately  with  team  members.  Using  appropriate  interpersonal  skills  allows  project  managers  to 
capitalize  on  the  strengths  of  all  team  members. 
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Examples  of  interpersonal  skills  that  a project  manager  uses  most  often  include: 

• Leadership.  Successful  projects  require  strong  leadership  skills.  Leadership  is  important  through  all 
phases  of  the  project  life  cycle.  There  are  multiple  leadership  theories  defining  leadership  styles  that 
should  be  used  as  needed  for  each  situation  or  team.  It  is  especially  important  to  communicate  the  vision 
and  inspire  the  project  team  to  achieve  high  performance. 

• Influencing.  Because  project  managers  often  have  little  or  no  direct  authority  over  team  members  in  a 
matrix  environment,  their  ability  to  influence  stakeholders  on  a timely  basis  is  critical  to  project  success. 
Key  influencing  skills  include: 

o Ability  to  be  persuasive  and  clearly  articulate  points  and  positions; 
o High  levels  of  active  and  effective  listening  skills; 

o Awareness  of,  and  consideration  for,  the  various  perspectives  in  any  situation;  and 

o Gathering  relevant  and  critical  information  to  address  important  issues  and  reach  agreements 
while  maintaining  mutual  trust. 

• Effective  decision  making.  This  involves  the  ability  to  negotiate  and  influence  the  organization  and  the 
project  management  team.  Some  guidelines  for  decision  making  include: 

o Focus  on  goals  to  be  served, 
o Follow  a decision-making  process, 
o Study  the  environmental  factors, 
o Analyze  available  information, 
o Develop  personal  qualities  of  the  team  members, 
o Stimulate  team  creativity,  and 
o Manage  risk. 

9.4.3  Manage  Project  Team:  Outputs 
9.4.3.1  Change  Requests 

Staffing  changes,  whether  by  choice  or  by  uncontrollable  events,  can  affect  the  rest  of  the  project  management 
plan.  When  staffing  issues  disrupt  the  project  team  from  adhering  to  the  project  management  plan  such  as  causing 
the  schedule  to  be  extended  or  the  budget  to  be  exceeded,  a change  request  can  be  processed  through  the 
Perform  Integrated  Change  Control  process.  Staffing  changes  may  include  moving  people  to  different  assignments, 
outsourcing  some  of  the  work,  and  replacing  team  members  who  leave. 
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Preventive  actions  are  those  actions  that  are  developed  to  reduce  the  probability  and/or  impact  of  problems 
before  they  occur.  These  actions  may  include  cross  training  to  reduce  problems  during  project  team  member 
absences  and  additional  role  clarification  to  ensure  all  responsibilities  are  fulfilled. 

9.4.3.2  Project  Management  Plan  Updates 

Elements  of  the  project  management  plan  that  may  be  updated  include,  but  are  not  limited  to,  the  human 
resource  management  plan. 

9.4.3.3  Project  Documents  Updates 

Project  documents  that  may  indirectly  be  updated  include,  but  are  not  limited  to: 

• Issue  log, 

• Roles  description,  and 

• Project  staff  assignments. 

9.4.3.4  Enterprise  Environmental  Factors  Updates 

Enterprise  environmental  factors  that  may  require  updates  as  a result  of  the  Manage  Project  Team  process 
include,  but  are  not  limited  to: 

• Input  to  organizational  performance  appraisals,  and 

• Personnel  skill  updates. 

9.4.3.5  Organizational  Process  Assets  Updates 

Organizational  process  assets  that  may  require  updates  as  a result  of  the  Manage  Project  Team  process  include, 
but  are  not  limited  to: 

• Historical  information  and  lessons  learned  documentation, 

• Templates,  and 

• Organizational  standard  processes. 
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II 

PROJECT  COMMUNICATIONS  MANAGEMENT 


Project  Communications  Management  includes  the  processes  that  are  required  to  ensure  timely  and  appropriate 
planning,  collection,  creation,  distribution,  storage,  retrieval,  management,  control,  monitoring,  and  the  ultimate 
disposition  of  project  information.  Project  managers  spend  most  of  their  time  communicating  with  team  members 
and  other  project  stakeholders,  whether  they  are  internal  (at  all  organizational  levels)  or  external  to  the  organization. 
Effective  communication  creates  a bridge  between  diverse  stakeholders  who  may  have  different  cultural  and 
organizational  backgrounds,  different  levels  of  expertise,  and  different  perspectives  and  interests,  which  impact  or 
have  an  influence  upon  the  project  execution  or  outcome. 

Figure  1 0-1  provides  an  overview  of  the  Project  Communications  Management  processes,  which  are  as  follows: 

10.1  Plan  Communications  Management — The  process  of  developing  an  appropriate  approach  and 
plan  for  project  communications  based  on  stakeholder’s  information  needs  and  requirements,  and 
available  organizational  assets. 

10.2  Manage  Communications — The  process  of  creating,  collecting,  distributing,  storing,  retrieving  and 
the  ultimate  disposition  of  project  information  in  accordance  with  the  communications  management 
plan. 

10.3  Control  Communications — The  process  of  monitoring  and  controlling  communications  throughout 
the  entire  project  life  cycle  to  ensure  the  information  needs  of  the  project  stakeholders  are  met. 

These  processes  interact  with  each  other  and  with  processes  in  other  Knowledge  Areas  as  described  in  detail 
in  Section  3 and  Annex  A1. 

The  communication  activities  involved  in  these  processes  may  often  have  many  potential  dimensions  that  need 
to  be  considered,  including,  but  not  limited  to: 

• Internal  (within  the  project)  and  external  (customer,  vendors,  other  projects,  organizations,  the  public); 

• Formal  (reports,  minutes,  briefings)  and  informal  (emails,  memos,  ad-hoc  discussions); 

• Vertical  (up  and  down  the  organization)  and  horizontal  (with  peers); 

• Official  (newsletters,  annual  report)  and  unofficial  (off  the  record  communications);  and 

• Written  and  oral,  and  verbal  (voice  inflections)  and  nonverbal  (body  language). 
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Most  communication  skills  are  common  for  both  general  management  and  project  management,  such  as,  but 
not  limited  to: 

• Listening  actively  and  effectively; 

• Questioning  and  probing  ideas  and  situations  to  ensure  better  understanding; 

• Educating  to  increase  team’s  knowledge  so  that  they  can  be  more  effective; 

• Fact-finding  to  identify  or  confirm  information; 

• Setting  and  managing  expectations; 

• Persuading  a person,  a team,  or  an  organization  to  perform  an  action; 

• Motivating  to  provide  encouragement  or  reassurance; 

• Coaching  to  improve  performance  and  achieve  desired  results; 

• Negotiating  to  achieve  mutually  acceptable  agreements  between  parties; 

• Resolving  conflict  to  prevent  disruptive  impacts;  and 

• Summarizing,  recapping,  and  identifying  the  next  steps. 
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Figure  10-1.  Project  Communications  Management  Overview 
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10.1  Plan  Communications  Management 

Plan  Communications  Management  is  the  process  of  developing  an  appropriate  approach  and  plan  for  project 
communications  based  on  stakeholder’s  information  needs  and  requirements,  and  available  organizational  assets. 
The  key  benefit  of  this  process  is  that  it  identifies  and  documents  the  approach  to  communicate  most  effectively 
and  efficiently  with  stakeholders.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in 
Figure  1 0-2.  Figure  1 0-3  depicts  the  data  flow  diagram  of  the  Plan  Communications  Management  process. 
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Figure  10-2.  Plan  Communications  Management:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  10-3.  Plan  Communications  Management  Data  Flow  Diagram 
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Planning  the  project  communications  is  important  to  the  ultimate  success  of  any  project.  Inadequate 
communications  planning  may  lead  to  problems  such  as  delay  in  message  delivery,  communication  of  information 
to  the  wrong  audience,  or  insufficient  communication  to  the  stakeholders  and  misunderstanding  or  misinterpretation 
of  the  message  communicated. 

On  most  projects,  communication  planning  is  performed  very  early,  such  as  during  project  management  plan 
development.  This  allows  appropriate  resources,  such  as  time  and  budget,  to  be  allocated  to  communication 
activities.  Effective  communication  means  that  the  information  is  provided  in  the  right  format,  at  the  right  time,  to 
the  right  audience,  and  with  the  right  impact.  Efficient  communication  means  providing  only  the  information  that 
is  needed. 

While  all  projects  share  the  need  to  communicate  project  information,  the  information  needs  and  methods  of 
distribution  may  vary  widely.  In  addition,  the  methods  of  storage,  retrieval,  and  ultimate  disposition  of  the  project 
information  need  to  be  considered  and  appropriately  documented  during  this  process.  Important  considerations 
that  may  need  to  be  taken  into  account  include,  but  are  not  limited  to: 

• Who  needs  what  information,  and  who  is  authorized  to  access  that  information; 

• When  they  will  need  the  information; 

• Where  the  information  should  be  stored; 

• What  format  the  information  should  be  stored  in; 

• How  the  information  can  be  retrieved;  and 

• Whether  time  zone,  language  barriers,  and  cross-cultural  considerations  need  to  be  taken  into  account. 

The  results  of  the  Plan  Communications  Management  process  should  be  reviewed  regularly  throughout  the 
project  and  revised  as  needed  to  ensure  continued  applicability. 

10.1.1  Plan  Communications  Management:  Inputs 

10.1.1.1  Project  Management  Plan 

Described  in  Section  4. 2.3.1.  The  project  management  plan  provides  information  on  how  the  project  will  be 
executed,  monitored,  controlled,  and  closed. 
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10.1.1.2  Stakeholder  Register 

Described  in  Section  13.1.3.1.  The  stakeholder  register  provides  the  information  needed  to  plan  the 
communication  with  project  stakeholders. 

10.1.1.3  Enterprise  Environmental  Factors 

Described  in  Section  2.1.5.  The  Plan  Communications  Management  process  is  tightly  linked  with  enterprise 
environmental  factors,  since  the  structure  of  an  organization  will  have  a major  effect  on  the  project’s  communication 
requirements.  All  enterprise  environmental  factors  described  in  Section  2.1 .5  are  used  as  inputs  for  this  process, 
since  communications  need  to  be  adapted  to  the  project  environment. 

10.1.1.4  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  All  organizational  process  assets  described  in  Section  2.1 .4  are  used  as  inputs  to  the 
Plan  Communications  Management  process.  Of  these,  lessons  learned  and  historical  information  are  of  particular  10 
importance  because  they  can  provide  insights  on  both  the  decisions  taken  regarding  communications  issues  and 
the  results  of  those  decisions  in  previous  similar  projects.  These  can  be  used  as  guiding  information  to  plan  the 
communication  activities  for  the  current  project. 

10.1.2  Plan  Communications  Management:  Tools  and  Techniques 

10.1.2.1  Communication  Requirements  Analysis 

The  analysis  of  the  communication  requirements  determines  the  information  needs  of  the  project  stakeholders. 

These  requirements  are  defined  by  combining  the  type  and  format  of  information  needed  with  an  analysis  of  the 
value  of  that  information.  Project  resources  should  be  expended  only  on  communicating  information  that  contributes 
to  the  success  of  the  project  or  where  a lack  of  communication  can  lead  to  failure. 
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The  project  manager  should  also  consider  the  number  of  potential  communication  channels  or  paths  as  an 
indicator  of  the  complexity  of  a project’s  communications.  The  total  number  of  potential  communication  channels 
is  n(n  - 1)/2,  where  n represents  the  number  of  stakeholders.  For  example,  a project  with  1 0 stakeholders  has 
10(10  - 1)/2  = 45  potential  communication  channels.  As  a result,  a key  component  of  planning  the  project’s 
actual  communications  is  to  determine  and  limit  who  will  communicate  with  whom  and  who  will  receive  what 
information. 

Sources  of  information  typically  used  to  identify  and  define  project  communication  requirements  include,  but 
are  not  limited  to: 

• Organizational  charts; 

• Project  organization  and  stakeholder  responsibility  relationships; 

• Disciplines,  departments,  and  specialties  involved  in  the  project; 

• Logistics  of  how  many  persons  will  be  involved  with  the  project  and  at  which  locations; 

• Internal  information  needs  (e.g.,  when  communicating  within  organizations); 

• External  information  needs  (e.g.,  when  communicating  with  the  media,  public,  or  contractors);  and 

• Stakeholder  information  and  communication  requirements  from  within  the  stakeholder  register. 

10.1.2.2  Communication  Technology 

The  methods  used  to  transfer  information  among  project  stakeholders  may  vary  significantly.  For  example,  a 
project  team  may  use  techniques  from  brief  conversations  to  extended  meetings,  or  from  simple  written  documents 
to  extensive  materials  (e.g.,  schedules,  databases,  and  websites),  which  are  accessible  online  as  methods  of 
communication. 

Factors  that  can  affect  the  choice  of  communication  technology  include: 

• Urgency  of  the  need  for  information.  There  is  a need  to  consider  the  urgency,  frequency,  and  format 
of  the  information  to  be  communicated  as  they  may  vary  from  project  to  project  and  also  within  different 
stages  of  a project. 

• Availability  of  technology.  There  is  a need  to  ensure  that  the  technology  that  is  required  to  facilitate 
communication  is  compatible,  available,  and  accessible  for  all  stakeholders  throughout  the  life  of  the 
project. 
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• Ease  of  Use.  There  is  a need  to  ensure  that  the  choice  of  communication  technologies  is  suitable  for 
project  participants  and  that  appropriate  training  events  are  planned  for,  where  appropriate. 

• Project  environment.  There  is  a need  to  determine  if  the  team  will  meet  and  operate  on  a face-to-face 
basis  or  in  a virtual  environment;  whether  they  will  be  located  in  one  or  multiple  time  zones;  whether 
they  will  use  multiple  languages  for  communication;  and  finally,  whether  there  are  any  other  project 
environmental  factors,  such  as  culture,  which  may  affect  communications. 

• Sensitivity  and  confidentiality  of  the  information.  There  is  a need  to  determine  if  the  information 
to  be  communicated  is  sensitive  or  confidential  and  whether  or  not  additional  security  measures  need 
to  be  taken.  Also,  the  most  appropriate  way  to  communicate  the  information  should  be  considered. 


10.1.2.3  Communication  Models 


The  communication  models  used  to  facilitate  communications  and  the  exchange  of  information  may  vary  from 
project  to  project  and  also  within  different  stages  of  the  same  project.  A basic  communication  model,  shown  in 
Figure  10-4,  consists  of  two  parties,  defined  as  the  sender  and  receiver.  Medium  is  the  technology  medium  and 
includes  the  mode  of  communication  while  noise  includes  any  interference  or  barriers  that  might  compromise  the 
delivery  of  the  message.  The  sequence  of  steps  in  a basic  communication  model  is: 

• Encode.  Thoughts  or  ideas  are  translated  (encoded)  into  language  by  the  sender. 

• Transmit  Message.  This  information  is  then  sent  by  the  sender  using  communication  channel  (medium). 
The  transmission  of  this  message  may  be  compromised  by  various  factors  (e.g.,  distance,  unfamiliar 
technology,  inadequate  infrastructure,  cultural  difference,  and  lack  of  background  information).  These 
factors  are  collectively  termed  as  noise. 

• Decode.  The  message  is  translated  by  the  receiver  back  into  meaningful  thoughts  or  ideas. 

• Acknowledge.  Upon  receipt  of  a message,  the  receiver  may  signal  (acknowledge)  receipt  of  the  message 
but  this  does  not  necessarily  mean  agreement  with  or  comprehension  of  the  message. 

• Feedback/Response.  When  the  received  message  has  been  decoded  and  understood,  the  receiver 
encodes  thoughts  and  ideas  into  a message  and  then  transmits  this  message  to  the  original  sender. 
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Figure  10-4.  Basic  Communication  Model 


The  components  of  the  basic  communication  model  need  to  be  considered  when  project  communications 
are  discussed.  As  part  of  the  communications  process,  the  sender  is  responsible  for  the  transmission 
of  the  message,  ensuring  the  information  being  communicated  is  clear  and  complete,  and  confirming  the 
communication  is  correctly  understood.  The  receiver  is  responsible  for  ensuring  that  the  information  is  received 
in  its  entirety,  understood  correctly,  and  acknowledged  or  responded  to  appropriately. 

There  are  many  challenges  in  using  these  components  to  effectively  communicate  with  project  stakeholders, 
such  as  in  a highly  technical,  multinational  project  team.  Successful  communication  of  a technical  concept 
from  one  team  member  to  another  team  member  in  a different  country  could  involve  encoding  the  message  in 
the  appropriate  language,  sending  the  message  using  a variety  of  technologies,  and  having  the  receiver  decode 
the  message  into  his  or  her  native  language  and  then  reply  or  provide  feedback.  Any  noise  introduced  along 
the  way  may  compromise  the  original  meaning  of  the  message.  In  this  example,  there  are  multiple  factors  that 
may  lead  to  the  intended  meaning  of  the  message  being  misunderstood  or  misinterpreted. 

10.1.2.4  Communication  Methods 

There  are  several  communication  methods  that  are  used  to  share  information  among  project  stakeholders. 
These  methods  are  broadly  classified  as  follows: 
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• Interactive  communication.  Between  two  or  more  parties  performing  a multidirectional  exchange 
of  information.  It  is  the  most  efficient  way  to  ensure  a common  understanding  by  all  participants  on 
specified  topics,  and  includes  meetings,  phone  calls,  instant  messaging,  video  conferencing,  etc. 

• Push  communication.  Sent  to  specific  recipients  who  need  to  receive  the  information.  This  ensures 
that  the  information  is  distributed  but  does  not  ensure  that  it  actually  reached  or  was  understood  by  the 
intended  audience.  Push  communications  include  letters,  memos,  reports,  emails,  faxes,  voice  mails, 
blogs,  press  releases,  etc. 

• Pull  communication.  Used  for  very  large  volumes  of  information,  or  for  very  large  audiences,  and 
requires  the  recipients  to  access  the  communication  content  at  their  own  discretion.  These  methods 
include  intranet  sites,  e-learning,  lessons  learned  databases,  knowledge  repositories,  etc. 

The  choices  of  communication  methods  that  are  used  for  a project  may  need  to  be  discussed  and  agreed  upon 
by  the  project  stakeholders  based  on  communication  requirements;  cost  and  time  constraints;  and  familiarity  and 
availability  of  the  required  tools  and  resources  that  may  be  applicable  to  the  communications  process. 

10.1.2.5  Meetings 

Described  in  Section  4. 3.2. 3.  The  Plan  Communications  Management  process  requires  discussion  and  dialogue 
with  the  project  team  to  determine  the  most  appropriate  way  to  update  and  communicate  project  information, 
and  to  respond  to  requests  from  various  stakeholders  for  that  information.  These  discussions  and  dialogue  are 
commonly  facilitated  through  meetings,  which  may  be  conducted  face  to  face  or  online  and  in  different  locations, 
such  as  the  project  site  or  the  customer’s  site. 

There  are  several  types  of  project-related  meetings  where  project  communications  may  occur.  Most  project 
meetings  consist  of  stakeholders  coming  together  for  the  purpose  of  resolving  problems  or  making  decisions. 
Although  casual  discussions  may  be  construed  as  a meeting,  most  project  meetings  are  more  formal  with  a 
prearranged  time,  place,  and  agenda.  Typical  meetings  begin  with  a defined  list  of  issues  to  be  discussed,  which  are 
circulated  in  advance  with  minutes  and  other  information  documented  specifically  for  the  meeting.  This  information 
is  then  disseminated  to  other  appropriate  stakeholders  on  an  as-needed  basis. 
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10.1.3  Plan  Communications  Management:  Outputs 

10.1.3.1  Communications  Management  Plan 

The  communications  management  plan  is  a component  of  the  project  management  plan  that  describes  how 
project  communications  will  be  planned,  structured,  monitored,  and  controlled.  The  plan  contains  the  following 
information: 

• Stakeholder  communication  requirements; 

• Information  to  be  communicated,  including  language,  format,  content,  and  level  of  detail; 

• Reason  for  the  distribution  of  that  information; 

• Time  frame  and  frequency  for  the  distribution  of  required  information  and  receipt  of  acknowledgment  or 
response,  if  applicable; 

• Person  responsible  for  communicating  the  information; 

• Person  responsible  for  authorizing  release  of  confidential  information; 

• Person  or  groups  who  will  receive  the  information; 

• Methods  or  technologies  used  to  convey  the  information,  such  as  memos,  e-mail,  and/or  press  releases; 

• Resources  allocated  for  communication  activities,  including  time  and  budget; 

• Escalation  process  identifying  time  frames  and  the  management  chain  (names)  for  escalation  of  issues 
that  cannot  be  resolved  at  a lower  staff  level; 

• Method  for  updating  and  refining  the  communications  management  plan  as  the  project  progresses  and 
develops; 

• Glossary  of  common  terminology; 

• Flow  charts  of  the  information  flow  in  the  project,  workflows  with  possible  sequence  of  authorization,  list 
of  reports,  and  meeting  plans,  etc.;  and 

• Communication  constraints  usually  derived  from  a specific  legislation  or  regulation,  technology,  and 
organizational  policies,  etc. 


296  ©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKs‘  Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


10  - PROJECT  COMMUNICATIONS  MANAGEMENT 


The  communications  management  plan  can  also  include  guidelines  and  templates  for  project  status  meetings, 
project  team  meetings,  e-meetings,  and  e-mail  messages.  The  use  of  a project  website  and  project  management 
software  can  also  be  included  if  these  are  to  be  used  in  the  project. 

10.1.3.2  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Project  schedule,  and 

• Stakeholder  register. 


10.2  Manage  Communications 

Manage  Communications  is  the  process  of  creating,  collecting,  distributing,  storing,  retrieving,  and  the  ultimate 
disposition  of  project  information  in  accordance  to  the  communications  management  plan.  The  key  benefit  of  this 
process  is  that  it  enables  an  efficient  and  effective  communications  flow  between  project  stakeholders.  The  inputs, 
tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  10-5.  Figure  10-6  depicts  the  data  flow 
diagram  of  the  Manage  Communications  process. 
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Figure  10-5.  Manage  Communications:  Inputs,  Tools  & Techniques,  and  Outputs 
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Project  Communications  Management 


Figure  10-6.  Manage  Communications  Data  Flow  Diagram 

This  process  goes  beyond  the  distribution  of  relevant  information  and  seeks  to  ensure  that  the  information  being 
communicated  to  project  stakeholders  has  been  appropriately  generated,  as  well  as  received  and  understood.  It 
also  provides  opportunities  for  stakeholders  to  make  requests  for  further  information,  clarification,  and  discussion. 
Techniques  and  considerations  for  effective  communications  management  include,  but  are  not  limited  to,  the 
following: 

• Sender-receiver  models.  Incorporating  feedback  loops  to  provide  opportunities  for  interaction/ 
participation  and  remove  barriers  to  communication. 

• Choice  of  media.  Situation  specifics  as  to  when  to  communicate  in  writing  versus  orally,  when  to  prepare 
an  informal  memo  versus  a formal  report,  and  when  to  communicate  face  to  face  versus  by  e-mail. 

• Writing  style.  Appropriate  use  of  active  versus  passive  voice,  sentence  structure,  and  word  choice. 
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• Meeting  management  techniques.  Preparing  an  agenda  and  dealing  with  conflicts. 

• Presentation  techniques.  Awareness  of  the  impact  of  body  language  and  design  of  visual  aids. 

• Facilitation  techniques.  Building  consensus  and  overcoming  obstacles. 

• Listening  techniques.  Listening  actively  (acknowledging,  clarifying,  and  confirming  understanding)  and 
removal  of  barriers  that  adversely  affect  comprehension. 

10.2.1  Manage  Communications:  Inputs 

10.2.1.1  Communications  Management  Plan 

Described  in  Section  1 0.1 .3.1 . The  communications  management  plan  describes  how  project  communications 
will  be  planned,  structured,  monitored,  and  controlled. 

10.2.1.2  Work  Performance  Reports  10 

Described  in  Section  4. 4.3. 2.  Work  performance  reports  are  a collection  of  project  performance  and  status 
information  that  may  be  used  to  facilitate  discussion  and  to  create  communications.  To  optimize  this  process,  it  is 
important  that  reports  be  comprehensive,  accurate,  and  available  in  a timely  manner. 

10.2.1.3  Enterprise  Environmental  Factors 

Described  in  Section  2.1.5.  Specific  enterprise  environmental  factors  that  can  influence  the  Manage 
Communications  process  include,  but  are  not  limited  to: 

• Organizational  culture  and  structure, 

• Government  or  industry  standards  and  regulations,  and 

• Project  management  information  system. 

10.2.1.4  Organizational  Process  Assets 

Described  in  Section  2.1.4.  Organizational  process  assets  that  can  influence  the  Manage  Communications 
process  include,  but  are  not  limited  to: 
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• Policies,  procedures,  processes,  and  guidelines  regarding  communications  management; 

• Templates;  and 

• Historical  information  and  lessons  learned. 

10.2.2  Manage  Communications:  Tools  and  Techniques 

10.2.2.1  Communication  Technology 

Described  in  Section  10.1.2.2.  The  choice  of  communication  technology  is  an  important  consideration  in  the 
Manage  Communications  process.  As  this  can  vary  significantly  from  project  to  project  and  also  throughout  the  life 
of  a project,  the  focus  is  to  ensure  that  the  choice  is  appropriate  for  the  information  that  is  being  communicated. 

10.2.2.2  Communication  Models 

Described  in  Section  10.1.2.3.  The  choice  of  communication  models  is  an  important  consideration 
in  this  process.  As  the  components  in  the  communications  all  contribute  toward  an  effective  and  efficient 
communications  process,  the  focus  is  to  ensure  that  the  choice  of  the  communication  model  is  appropriate  for 
the  project  that  is  undertaken  and  that  any  barriers  (noise)  are  identified  and  managed. 

10.2.2.3  Communication  Methods 

Described  in  Section  10.1.2.4.  The  choice  of  communication  methods  is  an  important  consideration  in  this 
process.  As  there  can  be  many  potential  barriers  and  challenges  during  this  process,  the  focus  is  to  ensure  that 
the  information  that  has  been  created  and  distributed  has  been  received  and  understood  to  enable  response  and 
feedback. 

10.2.2.4  Information  Management  Systems 

Project  information  is  managed  and  distributed  using  a variety  of  tools,  including: 

• Hard-copy  document  management:  letters,  memos,  reports,  and  press  releases; 

• Electronic  communications  management:  e-mail,  fax,  voice  mail,  telephone,  video  and  web  conferencing, 
websites,  and  web  publishing;  and 

• Electronic  project  management  tools:  web  interfaces  to  scheduling  and  project  management  software, 
meeting  and  virtual  office  support  software,  portals,  and  collaborative  work  management  tools. 
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10.2.2.5  Performance  Reporting 

Performance  reporting  is  the  act  of  collecting  and  distributing  performance  information,  including  status  reports, 
progress  measurements,  and  forecasts.  Performance  reporting  involves  the  periodic  collection  and  analysis  of 
baseline  versus  actual  data  to  understand  and  communicate  the  project  progress  and  performance  as  well  as  to 
forecast  the  project  results. 

Performance  reporting  needs  to  provide  information  at  an  appropriate  level  for  each  audience.  The  format 
may  range  from  a simple  status  report  to  more  elaborate  reports  and  may  be  prepared  regularly  or  on  an 
exception  basis.  A simple  status  report  might  show  performance  information,  such  as  percent  complete  or  status 
dashboards  for  each  area  (i.e.,  scope,  schedule,  cost,  and  quality).  More  elaborate  reports  may  include: 

• Analysis  of  past  performance, 

• Analysis  of  project  forecasts  (including  time  and  cost), 

• Current  status  of  risks  and  issues, 

• Work  completed  during  the  period,  10 

• Work  to  be  completed  in  the  next  period, 

• Summary  of  changes  approved  in  the  period,  and 

• Other  relevant  information,  which  is  reviewed  and  discussed. 

10.2.3  Manage  Communications:  Outputs 

10.2.3.1  Project  Communications 

The  Manage  Communications  process  involves  the  activities  that  are  required  for  information  to  be  created, 
distributed,  received,  acknowledged,  and  understood.  Project  communications  may  include  but  are  not  limited  to: 
performance  reports,  deliverables  status,  schedule  progress,  and  cost  incurred.  Project  communications  can  vary 
significantly  and  are  influenced  by  factors  such  as,  but  not  limited  to,  the  urgency  and  impact  of  the  message,  its 
method  of  delivery,  and  level  of  confidentiality. 
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10.2.3.2  Project  Management  Plan  Updates 

The  project  management  plan  provides  information  on  project  baselines,  communications  management,  and 
stakeholder  management.  Each  of  these  areas  may  require  updates  based  upon  the  current  performance  of  the 
project  against  the  performance  measurement  baseline  (PMB).  The  performance  measurement  baseline  is  an 
approved  plan  for  the  project  work  to  which  the  project  execution  is  compared,  and  deviations  are  measured 
for  management  control.  The  performance  measurement  baseline  typically  integrates  scope,  schedule,  and  cost 
parameters  of  a project,  but  may  also  include  technical  and  quality  parameters. 

10.2.3.3  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Issue  log, 

• Project  schedule,  and 

• Project  funding  requirements. 

10.2.3.4  Organizational  Process  Assets  Updates 

The  organizational  process  assets,  which  may  be  updated  include,  but  are  not  limited  to: 

• Stakeholder  notifications.  Information  may  be  provided  to  stakeholders  about  resolved  issues,  approved 
changes,  and  general  project  status. 

• Project  reports.  Formal  and  informal  project  reports  describe  project  status  and  include  lessons  learned, 
issue  logs,  project  closure  reports,  and  outputs  from  other  Knowledge  Areas  (Sections  4-13). 

• Project  presentations.  The  project  team  provides  information  formally  or  informally  to  any  or  all  of  the 
project  stakeholders.  The  information  and  presentation  method  should  be  relevant  to  the  needs  of  the 
audience. 

• Project  records.  Project  records  may  include  correspondence,  memos,  meeting  minutes,  and  other 
documents  describing  the  project.  This  information  should,  to  the  extent  possible  and  appropriate, 
be  maintained  in  an  organized  manner.  Project  team  members  can  also  maintain  records  in  a project 
notebook  or  register,  which  could  be  physical  or  electronic. 
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• Feedback  from  stakeholders.  Information  received  from  stakeholders  concerning  project  operations  is 
distributed  and  used  to  modify  or  improve  future  performance  of  the  project. 

• Lessons  learned  documentation.  Documentation  includes  the  causes  of  issues,  reasoning  behind 
the  corrective  action  chosen,  and  other  types  of  lessons  learned  about  communications  management. 
Lessons  learned  need  to  be  documented  and  distributed  so  that  it  becomes  part  of  the  historical  database 
for  both  the  project  and  the  performing  organization. 

10.3  Control  Communications 

Control  Communications  is  the  process  of  monitoring  and  controlling  communications  throughout  the  entire 
project  life  cycle  to  ensure  the  information  needs  of  the  project  stakeholders  are  met.  The  key  benefit  of  this  process 
is  that  it  ensures  an  optimal  information  flow  among  all  communication  participants,  at  any  moment  in  time.  The 
inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  1 0-7.  Figure  1 0-8  depicts  the  data 
flow  diagram  of  the  Control  Communications  process. 
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Figure  10-7.  Control  Communications:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  10-8.  Control  Communications  Data  Flow  Diagram 

The  Control  Communications  process  can  trigger  an  iteration  of  the  Plan  Communications  Management  and/or 
Manage  Communications  processes.  This  iteration  illustrates  the  continuous  nature  of  the  Project  Communications 
Management  processes.  Specific  communication  elements,  such  as  issues  or  key  performance  indicators  (e.g., 
actual  vs.  planned  schedule,  cost,  and  quality),  may  trigger  an  immediate  revision,  while  others  may  not.  The  impact 
and  repercussions  of  project  communications  should  be  carefully  evaluated  and  controlled  to  ensure  that  the  right 
message  is  delivered  to  the  right  audience  at  the  right  time. 

10.3.1  Control  Communications:  Inputs 

10.3.1.1  Project  Management  Plan 

Described  in  Section  4. 2.3.1.  The  project  management  plan  describes  how  the  project  will  be  executed, 
monitored,  controlled,  and  closed.  It  provides  valuable  information  for  the  Control  Communications  process  such 
as,  but  not  limited  to: 
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• Stakeholder  communication  requirements, 

• Reason  for  the  distribution  of  the  information, 

• Timeframe  and  frequency  for  the  distribution  of  required  information, 

• Individual  or  group  responsible  for  communication  of  the  information,  and 

• Individual  or  group  receiving  the  information. 

10.3.1.2  Project  Communications 

Described  in  Section  1 0.2. 3.1 . The  Control  Communications  process  involves  the  activities  that  are  required 
for  information  and  communications  to  be  monitored,  acted  upon,  and  released  to  stakeholders.  Project 
communications  come  from  multiple  sources  and  may  vary  significantly  in  their  format,  level  of  detail,  degree  of 
formality  and  confidentiality.  Project  communications  may  include  but  are  not  limited  to: 

• Deliverables  status, 

• Schedule  progress,  and  10 

• Costs  incurred. 

10.3.1.3  Issue  Log 

Described  in  Section  1 3.3. 3.1 . An  issue  log  is  used  to  document  and  monitor  the  resolution  of  issues.  It  may  be 
used  to  facilitate  communication  and  ensure  a common  understanding  of  issues.  A written  log  documents  and  helps 
to  monitor  who  is  responsible  for  resolving  specific  issues  by  a target  date.  Issue  resolution  addresses  obstacles 
that  can  block  the  team  from  achieving  its  goals.  This  information  is  important  to  the  Control  Communications 
process  as  it  provides  both  a repository  for  what  has  already  happened  in  the  project  and  a platform  for  subsequent 
communications  to  be  delivered. 

10.3.1.4  Work  Performance  Data 

Described  in  Section  4. 3. 3. 2.  Work  performance  data  organizes  and  summarizes  the  information  gathered, 
and  presents  the  results  of  comparative  analysis  to  the  performance  measurement  baseline. 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKe‘  Guide)  - Fifth  Edition 


305 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


10  - PROJECT  COMMUNICATIONS  MANAGEMENT 


10.3.1.5  Organizational  Process  Assets 

Described  in  Section  2.1.4.  The  organizational  process  assets  that  may  influence  the  Control  Communications 
process  include,  but  are  not  limited  to: 

• Report  templates; 

• Policies,  standards,  and  procedures  that  define  communications; 

• Specific  communication  technologies  available; 

• Allowed  communication  media; 

• Record  retention  policies;  and 

• Security  requirements. 

10.3.2  Control  Communications:  Tools  and  Techniques 

10.3.2.1  Information  Management  Systems 

An  information  management  system  provides  a set  of  standard  tools  for  the  project  manager  to  capture,  store, 
and  distribute  information  to  stakeholders  about  the  project’s  costs,  schedule  progress,  and  performance.  Some 
software  packages  allow  the  project  manager  to  consolidate  reports  from  several  systems  and  facilitate  report 
distribution  to  the  project  stakeholders.  Examples  of  distribution  formats  may  include  table  reporting,  spreadsheet 
analysis,  and  presentations.  Graphic  capabilities  can  be  used  to  create  visual  representations  of  project  performance 
information. 

10.3.2.2  Expert  Judgment 

Expert  judgment  is  often  relied  upon  by  the  project  team  to  assess  the  impact  of  the  project  communications, 
need  for  action  or  intervention,  actions  that  should  be  taken,  responsibility  for  taking  such  actions,  and  the  timeframe 
for  taking  action.  Expert  judgment  may  need  to  be  applied  to  technical  and/or  management  details  and  may  be 
provided  by  any  group  or  individual  with  specialized  knowledge  or  training,  such  as: 
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• Other  units  within  the  organization, 

• Consultants, 

• Stakeholders,  including  customers  or  sponsors, 

• Professional  and  technical  associations, 

• Industry  groups, 

• Subject  matter  experts,  and 

• Project  management  office  (PMO). 

The  project  manager,  in  collaboration  with  the  project  team,  then  determines  the  actions  required  to  ensure  that 
the  right  message  is  communicated  to  the  right  audience  at  the  right  time. 


10.3.2.3  Meetings 

The  Control  Communications  process  requires  discussion  and  dialogue  with  the  project  team  to  determine 
the  most  appropriate  way  to  update  and  communicate  project  performance,  and  to  respond  to  requests  from 
stakeholders  for  information.  These  discussions  and  dialogues  are  commonly  facilitated  through  meetings, 
which  may  be  conducted  face  to  face  or  online  and  in  different  locations,  such  as  the  project  site  or  the 
client’s  site.  Project  meetings  also  include  discussions  and  dialog  with  suppliers,  vendors,  and  other  project 
stakeholders. 


10.3.3  Control  Communications:  Outputs 

10.3.3.1  Work  Performance  Information 

Described  in  Section  4.4.1 .5.  Work  performance  information  organizes  and  summarizes  the  performance  data 
gathered.  This  performance  data  typically  provides  status  and  progress  information  on  the  project  at  the  level  of 
detail  required  by  the  various  stakeholders.  This  information  is  then  communicated  to  the  appropriate  stakeholders. 

10.3.3.2  Change  Requests 

Described  in  Section  4. 3.3. 3.  The  Control  Communications  process  often  results  in  the  need  for  adjustment, 
action,  and  intervention.  As  a result,  change  requests  will  be  generated  as  an  output.  These  change  requests  are 
processed  through  the  Perform  Integrated  Change  Control  process  (Section  4.5)  and  may  result  in: 
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• New  or  revised  cost  estimates,  activity  sequences,  schedule  dates,  resource  requirements,  and  analysis 
of  risk  response  alternatives; 

• Adjustments  to  the  project  management  plan  and  documents; 

• Recommendations  of  corrective  actions  that  may  bring  the  expected  future  performance  of  the  project 
back  in  line  with  the  project  management  plan;  and 

• Recommendations  of  preventive  actions  that  may  reduce  the  probability  of  incurring  future  negative 
project  performance. 

10.3.3.3  Project  Management  Plan  Updates 

Control  Communications  process  may  trigger  updates  to  the  communications  management  plan  as  well  as 
other  components  of  the  project  management  plan  (e.g.  stakeholders  and  human  resource  management  plans). 

10.3.3.4  Project  Documents  Updates 

Project  documents  may  be  updated  as  a result  of  the  Control  Communications  process.  These  updates  may 
include,  but  are  not  limited  to: 

• Forecasts, 

• Performance  reports,  and 

• Issue  log. 

10.3.3.5  Organizational  Process  Assets  Updates 

The  organizational  process  assets  that  may  be  updated  include,  but  are  not  limited  to,  report  formats  and 
lessons  learned  documentation.  This  documentation  may  become  part  of  the  historical  database  for  both  this 
project  and  the  performing  organization  and  may  include  the  causes  of  issues,  reasons  behind  the  corrective  action 
chosen,  and  other  types  of  lessons  learned  during  the  project. 
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11 

PROJECT  RISK  MANAGEMENT 


Project  Risk  Management  includes  the  processes  of  conducting  risk  management  planning,  identification, 
analysis,  response  planning,  and  controlling  risk  on  a project.  The  objectives  of  project  risk  management  are  to 
increase  the  likelihood  and  impact  of  positive  events,  and  decrease  the  likelihood  and  impact  of  negative  events 
in  the  project. 

Figure  1 1 -1  provides  an  overview  of  the  Project  Risk  Management  processes,  which  are  as  follows: 

11.1  Plan  Risk  Management — The  process  of  defining  how  to  conduct  risk  management  activities  for  a 
project. 

11.2  Identify  Risks — The  process  of  determining  which  risks  may  affect  the  project  and  documenting 
their  characteristics. 

11.3  Perform  Qualitative  Risk  Analysis — The  process  of  prioritizing  risks  for  further  analysis  or  action 
by  assessing  and  combining  their  probability  of  occurrence  and  impact. 

11.4  Perform  Quantitative  Risk  Analysis — The  process  of  numerically  analyzing  the  effect  of  identified 
risks  on  overall  project  objectives. 

11.5  Plan  Risk  Responses — The  process  of  developing  options  and  actions  to  enhance  opportunities  and 
to  reduce  threats  to  project  objectives. 

1 1 .6  Control  Risks — The  process  of  implementing  risk  response  plans,  tracking  identified  risks,  monitoring 
residual  risks,  identifying  new  risks,  and  evaluating  risk  process  effectiveness  throughout  the  project. 

These  processes  interact  with  each  other  and  with  processes  in  other  Knowledge  Areas  as  described  in  detail 
in  Section  3 and  Annex  A1. 
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Project  risk  is  an  uncertain  event  or  condition  that,  if  it  occurs,  has  a positive  or  negative  effect  on  one  or 
more  project  objectives  such  as  scope,  schedule,  cost,  and  quality.  A risk  may  have  one  or  more  causes  and, 
if  it  occurs,  it  may  have  one  or  more  impacts.  A cause  may  be  a given  or  potential  requirement,  assumption, 
constraint,  or  condition  that  creates  the  possibility  of  negative  or  positive  outcomes.  For  example,  causes  could 
include  the  requirement  of  an  environmental  permit  to  do  work,  or  having  limited  personnel  assigned  to  design  the 
project.  The  risk  is  that  the  permitting  agency  may  take  longer  than  planned  to  issue  a permit;  or,  in  the  case  of 
an  opportunity,  additional  development  personnel  may  become  available  who  can  participate  in  design,  and  they 
can  be  assigned  to  the  project.  If  either  of  these  uncertain  events  occurs,  there  may  be  an  impact  on  the  project, 
scope,  cost,  schedule,  quality,  or  performance.  Risk  conditions  may  include  aspects  of  the  project’s  or  organization’s 
environment  that  contribute  to  project  risk,  such  as  immature  project  management  practices,  lack  of  integrated 
management  systems,  concurrent  multiple  projects,  or  dependency  on  external  participants  who  are  outside  the 
project’s  direct  control. 

Project  risk  has  its  origins  in  the  uncertainty  present  in  all  projects.  Known  risks  are  those  that  have  been 
identified  and  analyzed,  making  it  possible  to  plan  responses  for  those  risks.  Known  risks  that  cannot  be  managed 
proactively,  should  be  assigned  a contingency  reserve.  Unknown  risks  cannot  be  managed  proactively  and  therefore 
may  be  assigned  a management  reserve.  A negative  project  risk  that  has  occurred  is  considered  an  issue. 

Individual  project  risks  are  different  from  overall  project  risk.  Overall  project  risk  represents  the  effect  of 
uncertainty  on  the  project  as  a whole.  It  is  more  than  the  sum  of  the  individual  risks  within  a project,  since  it  includes 
all  sources  of  project  uncertainty.  It  represents  the  exposure  of  stakeholders  to  the  implications  of  variations  in 
project  outcome,  both  positive  and  negative. 

Organizations  perceive  risk  as  the  effect  of  uncertainty  on  projects  and  organizational  objectives.  Organizations 
and  stakeholders  are  willing  to  accept  varying  degrees  of  risk  depending  on  their  risk  attitude.  The  risk  attitudes  of 
both  the  organization  and  the  stakeholders  may  be  influenced  by  a number  of  factors,  which  are  broadly  classified 
into  three  themes: 
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• Risk  appetite,  which  is  the  degree  of  uncertainty  an  entity  is  willing  to  take  on  in  anticipation  of  a reward. 

• Risk  tolerance,  which  is  the  degree,  amount,  or  volume  of  risk  that  an  organization  or  individual  will 
withstand. 

• Risk  threshold,  which  refers  to  measures  along  the  level  of  uncertainty  or  the  level  of  impact  at  which  a 
stakeholder  may  have  a specific  interest.  Below  that  risk  threshold,  the  organization  will  accept  the  risk. 
Above  that  risk  threshold,  the  organization  will  not  tolerate  the  risk. 

For  example,  an  organization’s  risk  attitude  may  include  its  appetite  for  uncertainty,  its  threshold  for  risk  levels 
that  are  unacceptable,  or  its  risk  tolerance  at  which  point  the  organization  may  select  a different  risk  response. 

Positive  and  negative  risks  are  commonly  referred  to  as  opportunities  and  threats.  The  project  may  be  accepted 
if  the  risks  are  within  tolerances  and  are  in  balance  with  the  rewards  that  may  be  gained  by  taking  the  risks.  Positive 
risks  that  offer  opportunities  within  the  limits  of  risk  tolerances  may  be  pursued  in  order  to  generate  enhanced 
value.  For  example,  adopting  an  aggressive  resource  optimization  technique  is  a risk  taken  in  anticipation  of  a 
reward  for  using  fewer  resources. 

Individuals  and  groups  adopt  attitudes  toward  risk  that  influence  the  way  they  respond.  These  risk  attitudes  are 
driven  by  perception,  tolerances,  and  other  biases,  which  should  be  made  explicit  wherever  possible.  A consistent 
approach  to  risk  should  be  developed  for  each  project,  and  communication  about  risk  and  its  handling  should 
be  open  and  honest.  Risk  responses  reflect  an  organization’s  perceived  balance  between  risk  taking  and  risk 
avoidance. 

To  be  successful,  an  organization  should  be  committed  to  address  risk  management  proactively  and  consistently 
throughout  the  project.  A conscious  choice  should  be  made  at  all  levels  of  the  organization  to  actively  identify  and 
pursue  effective  risk  management  during  the  life  of  the  project.  Project  risk  could  exist  at  the  moment  a project 
is  initiated.  Moving  forward  on  a project  without  a proactive  focus  on  risk  management  is  likely  to  lead  to  more 
problems  arising  from  unmanaged  threats. 
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Project  Risk 
Management  Overview 


I 


11.2  Identify  Risks 


.1  Inputs 

.1  Risk  management  plan 
.2  Cost  management  plan 
.3  Schedule  management  plan 
.4  Quality  management  plan 
.5  Human  resource 
management  plan 
.6  Scope  baseline 
.7  Activity  cost  estimates 
.8  Activity  duration  estimates 
.9  Stakeholder  register 
.10  Project  documents 
.11  Procurement  documents 
.12  Enterprise  environmental 
factors 

.13  Organizational  process  assets 

.2 Tools  &Techniques 
.1  Documentation  reviews 
.2  Information  gathering 
techniques 
.3  Checklist  analysis 
.4  Assumptions  analysis 
.5  Diagramming  techniques 
.6  SWOT  analysis 
.7  Expert  judgment 

. 3 Outputs 
.1  Risk  register 

v / 


11. S Plan  Risk  Responses 


.1  Inputs 

.1  Risk  management  plan 
.2  Risk  register 

.2  Tools  & Techniques 

.1  Strategies  for  negative  risks  or 
threats 

.2  Strategies  for  positive  risks  or 
opportunities 
.3  Contingent  response 
strategies 
.4  Expert  judgment 

.3  Outputs 

.1  Project  management  plan 
updates 

.2  Project  documents  updates 

v / 


11.3  Perform  Qualitative 
Risk  Analysis 


.1  Inputs 

.1  Risk  management  plan 
.2  Scope  baseline 
.3  Risk  register 
.4  Enterprise  environmental 
factors 

.5  Organizational  process  assets 

.2  Tools  & Techniques 
.1  Risk  probability  and  impact 
assessment 

.2  Probability  and  impact  matrix 
.3  Risk  data  quality  assessment 
.4  Risk  categorization 
.5  Risk  urgency  assessment 
.6  Expert  judgment 

.3  Outputs 

.1  Project  documents  updates 

v J 


11.6  Control  Risks 


.1  Inputs 

.1  Project  management  plan 
.2  Risk  register 
.3  Work  performance  data 
.4  Work  performance  reports 

.2  Tools  & Techniques 
.1  Risk  reassessment 
.2  Risk  audits 

.3  Variance  and  trend  analysis 
.4  Technical  performance 
measurement 
.5  Reserve  analysis 
.6  Meetings 

.3  Outputs 

.1  Work  performance  information 
.2  Change  requests 
.3  Project  management  plan 
updates 

.4  Project  documents  updates 
.5  Organizational  process  assets 
updates 

V / 


Figure  11-1.  Project  Risk  Management  Overview 
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11.1  Plan  Risk  Management 

Plan  Risk  Management  is  the  process  of  defining  how  to  conduct  risk  management  activities  for  a project.  The 
key  benefit  of  this  process  is  it  ensures  that  the  degree,  type,  and  visibility  of  risk  management  are  commensurate 
with  both  the  risks  and  the  importance  of  the  project  to  the  organization.  The  risk  management  plan  is  vital  to 
communicate  with  and  obtain  agreement  and  support  from  all  stakeholders  to  ensure  the  risk  management  process 
is  supported  and  performed  effectively  over  the  project  life  cycle.  The  inputs,  tools  and  techniques,  and  outputs  of 
this  process  are  depicted  in  Figure  1 1 -2.  Figure  1 1 -3  depicts  the  data  flow  diagram  of  the  process. 


Inputs 


.1  Project  management  plan 
.2  Project  charter 
.3  Stakeholder  register 
.4  Enterprise  environmental 
factors 

.5  Organizational  process 
assets 

V / 


Tools  & Techniques 


.1  Analytical  techniques 
.2  Expert  judgment 
.3  Meetings 

v _ J 


Outputs 


.1  Risk  management  plan 
V J 


Figure  11-2.  Plan  Risk  Management:  Inputs,  Tools  & Techniques,  and  Outputs 


Project  Risk  Management 


Figure  11-3.  Plan  Risk  Management  Data  Flow  Diagram 
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Careful  and  explicit  planning  enhances  the  probability  of  success  for  other  risk  management  processes.  Planning 
is  also  important  to  provide  sufficient  resources  and  time  for  risk  management  activities  and  to  establish  an  agreed- 
upon  basis  for  evaluating  risks.  The  Plan  Risk  Management  process  should  begin  when  a project  is  conceived  and 
should  be  completed  early  during  project  planning. 

11.1.1  Plan  Risk  Management:  Inputs 

11.1.1.1  Project  Management  Plan 

In  planning  risk  management,  all  approved  subsidiary  management  plans  and  baselines  should  be  taken  into 
consideration  in  order  to  make  the  risk  management  plan  consistent  with  them.  The  risk  management  plan  is  also 
a component  of  the  project  management  plan.  The  project  management  plan  provides  baseline  or  current  state  of 
risk-affected  areas  including  scope,  schedule,  and  cost. 

11.1.1.2  Project  Charter 

Described  in  Section  4.1 .3.1  .The  project  charter  can  provide  various  inputs  such  as  high-level  risks,  high-level 
project  descriptions,  and  high-level  requirements. 

1 1 .1 .1 .3  Stakeholder  Register 

Described  in  Section  13.1.3.1.  The  stakeholder  register,  which  contains  all  details  related  to  the  project’s 
stakeholders,  provides  an  overview  of  their  roles. 

11.1.1.4  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  The  enterprise  environmental  factors  that  can  influence  the  Plan  Risk  Management 
process  include,  but  are  not  limited  to,  risk  attitudes,  thresholds,  and  tolerances  that  describe  the  degree  of  risk 
that  an  organization  will  withstand. 

1 1 .1 .1 .5  Organizational  Process  Assets 

Described  in  Section  2.1.4.  The  organizational  process  assets  that  can  influence  the  Plan  Risk  Management 
process  include,  but  are  not  limited  to: 
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• Risk  categories, 

• Common  definitions  of  concepts  and  terms, 

• Risk  statement  formats, 

• Standard  templates, 

• Roles  and  responsibilities, 

• Authority  levels  for  decision  making,  and 

• Lessons  learned. 


11.1.2  Plan  Risk  Management:  Tools  and  Techniques 


11.1.2.1  Analytical  Techniques 

Analytical  techniques  are  used  to  understand  and  define  the  overall  risk  management  context  of  the  project. 
Risk  management  context  is  a combination  of  stakeholder  risk  attitudes  and  the  strategic  risk  exposure  of  a given 
project  based  on  the  overall  project  context.  For  example,  a stakeholder  risk  profile  analysis  may  be  performed  to 
grade  and  qualify  the  project  stakeholder  risk  appetite  and  tolerance.  Other  techniques,  such  as  the  use  of  strategic 
risk  scoring  sheets,  are  used  to  provide  a high-level  assessment  of  the  risk  exposure  of  the  project  based  on  the 
overall  project  context.  Depending  on  these  assessments,  the  project  team  can  allocate  appropriate  resources  and 
focus  on  the  risk  management  activities. 


11.1 .2.2  Expert  Judgment 

To  ensure  a comprehensive  establishment  of  the  risk  management  plan,  judgment,  and  expertise  should  be 
considered  from  groups  or  individuals  with  specialized  training  or  knowledge  on  the  subject  area,  such  as: 

• Senior  management, 

• Project  stakeholders, 

• Project  managers  who  have  worked  on  projects  in  the  same  area  (directly  or  through  lessons  learned), 

• Subject  matter  experts  (SMEs)  in  business  or  project  area, 

• Industry  groups  and  consultants,  and 

• Professional  and  technical  associations. 
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11.1.2.3  Meetings 

Project  teams  hold  planning  meetings  to  develop  the  risk  management  plan.  Attendees  at  these  meetings  may 
include  the  project  manager,  selected  project  team  members  and  stakeholders,  anyone  in  the  organization  with 
responsibility  to  manage  the  risk  planning  and  execution  activities,  and  others,  as  needed. 

High-level  plans  for  conducting  the  risk  management  activities  are  defined  in  these  meetings.  Risk  management 
cost  elements  and  schedule  activities  should  be  developed  for  inclusion  in  the  project  budget  and  schedule, 
respectively.  Risk  contingency  reserve  application  approaches  may  be  established  or  reviewed.  Risk  management 
responsibilities  should  be  assigned.  General  organizational  templates  for  risk  categories  and  definitions  of  terms 
such  as  levels  of  risk,  probability  by  type  of  risk,  impact  by  type  of  objectives,  and  the  probability  and  impact  matrix 
will  be  tailored  to  the  specific  project.  If  templates  for  other  steps  in  the  process  do  not  exist,  they  may  be  generated 
in  these  meetings.  The  outputs  of  these  activities  are  summarized  in  the  risk  management  plan. 

11.1.3  Plan  Risk  Management:  Outputs 
11.1.3.1  Risk  Management  Plan 

The  risk  management  plan  is  a component  of  the  project  management  plan  and  describes  how  risk  management 
activities  will  be  structured  and  performed.  The  risk  management  plan  includes  the  following: 

• Methodology.  Defines  the  approaches,  tools,  and  data  sources  that  will  be  used  to  perform  risk 
management  on  the  project. 

• Roles  and  responsibilities.  Defines  the  lead,  support,  and  risk  management  team  members  for  each 
type  of  activity  in  the  risk  management  plan,  and  clarifies  their  responsibilities. 

• Budgeting.  Estimates  funds  needed,  based  on  assigned  resources,  for  inclusion  in  the  cost  baseline  and 
establishes  protocols  for  application  of  contingency  and  management  reserves. 

• Timing.  Defines  when  and  how  often  the  risk  management  processes  will  be  performed  throughout  the 
project  life  cycle,  establishes  protocols  for  application  of  schedule  contingency  reserves,  and  establishes 
risk  management  activities  for  inclusion  in  the  project  schedule. 
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• Risk  categories.  Provide  a means  for  grouping  potential  causes  of  risk.  Several  approaches  can  be 
used,  for  example,  a structure  based  on  project  objectives  by  category.  A risk  breakdown  structure  (RBS) 
helps  the  project  team  to  look  at  many  sources  from  which  project  risk  may  arise  in  a risk  identification 
exercise.  Different  RBS  structures  will  be  appropriate  for  different  types  of  projects.  An  organization  can 
use  a previously  prepared  custom  categorization  framework,  which  may  take  the  form  of  a simple  list  of 
categories  or  may  be  structured  into  an  RBS.  The  RBS  is  a hierarchical  representation  of  risks  according 
to  their  risk  categories.  An  example  is  shown  in  Figure  1 1 -4. 


Beta  Distribution  Triangular  Distribution 


Beta  and  triangular  distributions  are  frequently  used  in  quantitative  risk  analysis.  The  data  shown  in  the  figure 
on  the  left  (Beta  Distribution)  is  one  example  of  a family  of  such  distributions  determined  by  two  "shape 
parameters”.  Other  commonly  used  distributions  include  the  uniform,  normal  and  lognormal.  In  these  charts 
the  horizontal  (X)  axes  represent  possible  values  of  time  or  cost  and  the  vertical  (Y)  axes  represent  relative 
likelihood. 


Figure  11-4.  Example  of  a Risk  Breakdown  Structure  (RBS) 

• Definitions  of  risk  probability  and  impact.  The  quality  and  credibility  of  the  risk  analysis  requires  that 
different  levels  of  risk  probability  and  impact  be  defined  that  are  specific  to  the  project  context.  General 
definitions  of  probability  levels  and  impact  levels  are  tailored  to  the  individual  project  during  the  Plan 
Risk  Management  process  for  use  in  subsequent  processes.  Table  11-1  is  an  example  of  definitions  of 
negative  impacts  that  could  be  used  in  evaluating  risk  impacts  related  to  four  project  objectives.  (Similar 
tables  may  be  established  with  a positive  impact  perspective).  Table  11-1  illustrates  both  relative  and 
numerical  (in  this  case,  nonlinear)  approaches. 
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Table  11-1.  Definition  of  Impact  Scales  for  Four  Project  Objectives 


Defined  Conditions  for  Impact  Scales  of  a Risk  on  Major  Project  Objectives 

(Examples  are  shown  for  negative  impacts  only) 

Project 

Objective 

Relative  or  numerical  scales  are  shown 

Very  low  /0.05 

Low  /O.IO 

Moderate  /0.20 

High/0.40 

Very  high  /0.80 

Cost 

Insignificant  cost 
increase 

< 10%  cost 
increase 

10  - 20%  cost 
increase 

20  - 40%  cost 
increase 

> 40%  cost 
increase 

Time 

Insignificant  time 
increase 

< 5%  time 
increase 

5 - 10%  time 
increase 

10  - 20%  time 
increase 

> 20%  time 
increase 

Scope 

Scope  decrease 
barely  noticeable 

Minor  areas  of 
scope  affected 

Major  areas  of 
scope  affected 

Scope  reduction 
unacceptable  to 
sponsor 

Project  end  item 
is  effectively 
useless 

Quality 

Quality  degradation 
barely  noticeable 

Only  very  demanding 
applications 
are  affected 

Quality  reduction 
requires  sponsor 
approval 

Quality  reduction 
unacceptable  to 
sponsor 

Project  end  item 
is  effectively 
useless 

This  table  presents  examples  of  risk  impact  definitions  for  four  different  project  objectives.  They  should  be  tailored  in  the 

Risk  Management  Planning  process  to  the  individual  project  and  to  the  organization's  risk  thresholds.  Impact  definitions  can  be 
developed  for  opportunities  in  a similar  way. 

• Probability  and  impact  matrix.  A probability  and  impact  matrix  is  a grid  for  mapping  the  probability 
of  each  risk  occurrence  and  its  impact  on  project  objectives  if  that  risk  occurs.  Risks  are  prioritized 
according  to  their  potential  implications  for  having  an  effect  on  the  project’s  objectives.  A typical 
approach  to  prioritizing  risks  is  to  use  a look-up  table  or  a probability  and  impact  matrix.  The  specific 
combinations  of  probability  and  impact  that  lead  to  a risk  being  rated  as  “high,”  “moderate,”  or  “low” 
importance  are  usually  set  by  the  organization. 

• Revised  stakeholders’  tolerances.  Stakeholders’  tolerances,  as  they  apply  to  the  specific  project,  may 
be  revised  in  the  Plan  Risk  Management  process. 

• Reporting  formats.  Reporting  formats  define  how  the  outcomes  of  the  risk  management  process  will 
be  documented,  analyzed,  and  communicated.  It  describes  the  content  and  format  of  the  risk  register  as 
well  as  any  other  risk  reports  required. 

• Tracking.  Tracking  documents  how  risk  activities  will  be  recorded  for  the  benefit  of  the  current  project 
and  how  risk  management  processes  will  be  audited. 
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1 1 .2  Identify  Risks 

Identify  Risks  is  the  process  of  determining  which  risks  may  affect  the  project  and  documenting  their 
characteristics.  The  key  benefit  of  this  process  is  the  documentation  of  existing  risks  and  the  knowledge  and  ability 
it  provides  to  the  project  team  to  anticipate  events.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process 
are  depicted  in  Figure  1 1 -5.  Figure  1 1 -6  depicts  the  data  flow  diagram  of  the  process. 


Inputs 


.1  Risk  management  plan 
.2  Cost  management  plan 
.3  Schedule  management 
plan 

.4  Quality  management  plan 
.5  Human  resource 
management  plan 
.6  Scope  baseline 
.7  Activity  cost  estimates 
.8  Activity  duration 
estimates 

.9  Stakeholder  register 
.10  Project  documents 
.11  Procurement  documents 
.12  Enterprise  environmental 
factors 

.13  Organizational  process 
assets 

V / 


Tools  & Techniques 


.1  Documentation  reviews 
.2  Information  gathering 
techniques 
.3  Checklist  analysis 
.4  Assumptions  analysis 
.5  Diagramming  techniques 
.6  SWOT  analysis 
.7  Expert  judgment 
V / 


Outputs 


.1  Risk  register 

v y 


Figure  11-5.  Identify  Risks:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  11-6.  Identify  Risks  Data  Flow  Diagram 


320  ©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKB  Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


11  - PROJECT  RISK  MANAGEMENT 


Participants  in  risk  identification  activities  may  include  the  following:  project  manager,  project  team  members, 
risk  management  team  (if  assigned),  customers,  subject  matter  experts  from  outside  the  project  team,  end 
users,  other  project  managers,  stakeholders,  and  risk  management  experts.  While  these  personnel  are  often  key 
participants  for  risk  identification,  all  project  personnel  should  be  encouraged  to  identify  potential  risks. 

Identify  risks  is  an  iterative  process,  because  new  risks  may  evolve  or  become  known  as  the  project  progresses 
through  its  life  cycle.  The  frequency  of  iteration  and  participation  in  each  cycle  will  vary  by  situation.  The  format  of 
the  risk  statements  should  be  consistent  to  ensure  that  each  risk  is  understood  clearly  and  unambiguously  in  order 
to  support  effective  analysis  and  response  development.  The  risk  statement  should  support  the  ability  to  compare 
the  relative  effect  of  one  risk  against  others  on  the  project.  The  process  should  involve  the  project  team  so  they  can 
develop  and  maintain  a sense  of  ownership  and  responsibility  for  the  risks  and  associated  risk  response  actions. 
Stakeholders  outside  the  project  team  may  provide  additional  objective  information. 


11.2.1  Identify  Risks:  Inputs 


11.2.1.1  Risk  Management  Plan 

Described  in  Section  1 1 .1 .3.1 . Key  elements  of  the  risk  management  plan  that  contribute  to  the  Identify  Risks 
process  are  the  assignments  of  roles  and  responsibilities,  provision  for  risk  management  activities  in  the  budget 
and  schedule,  and  categories  of  risk,  which  are  sometimes  expressed  as  a risk  breakdown  structure  (Figure  1 1 -4). 


11.2.1.2  Cost  Management  Plan 

Described  in  Section  7.1 .3.1.  The  cost  management  plan  provides  processes  and  controls  that  can  be  used  to 
help  identify  risks  across  the  project. 


1 1 .2.1 .3  Schedule  Management  Plan 

Described  in  Section  6. 1.3.1.  The  schedule  management  plan  provides  insight  to  project  time/schedule 
objectives  and  expectations  which  may  be  impacted  by  risks  (known  and  unknown). 


11.2.1.4  Quality  Management  Plan 

Described  in  Section  8.1 .3.1 . The  quality  management  plan  provides  a baseline  of  quality  measures  and  metrics 
for  use  in  identifying  risks. 
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11.2.1.5  Human  Resource  Management  Plan 

Described  in  Section  9.1 .3.1.  The  human  resource  management  plan  provides  guidance  on  how  project  human 
resources  should  be  defined,  staffed,  managed,  and  eventually  released.  It  can  also  contain  roles  and  responsibilities, 
project  organization  charts,  and  the  staffing  management  plan,  which  form  a key  input  to  identify  risk  process. 

11.2.1.6  Scope  Baseline 

Described  in  Section  5. 4.3.1.  Project  assumptions  are  found  in  the  project  scope  statement.  Uncertainty  in 
project  assumptions  should  be  evaluated  as  potential  causes  of  project  risk. 

The  WBS  is  a critical  input  to  identifying  risks  as  it  facilitates  an  understanding  of  the  potential  risks  at  both 
the  micro  and  macro  levels.  Risks  can  be  identified  and  subsequently  tracked  at  summary,  control  account,  and/or 
work  package  levels. 

1 1 .2.1 .7  Activity  Cost  Estimates 

Described  in  Section  7.2. 3.1 . Activity  cost  estimate  reviews  are  useful  in  identifying  risks  as  they  provide  a 
quantitative  assessment  of  the  likely  cost  to  complete  scheduled  activities  and  ideally  are  expressed  as  a range, 
with  the  width  of  the  range  indicating  the  degree(s)  of  risk.  The  review  may  result  in  projections  indicating  the 
estimate  is  either  sufficient  or  insufficient  to  complete  the  activity  (i.e.,  pose  a risk  to  the  project). 

1 1 .2.1 .8  Activity  Duration  Estimates 

Described  in  Section  6.5. 3.1 . Activity  duration  estimate  reviews  are  useful  in  identifying  risks  related  to  the  time 
allowances  for  the  activities  or  project  as  a whole,  again  with  the  width  of  the  range  of  such  estimates  indicating 
the  relative  degree(s)  of  risk. 

11.2.1.9  Stakeholder  Register 

Described  in  Section  1 3.1 .3.1 . Information  about  the  stakeholders  is  useful  for  soliciting  inputs  to  identify  risks, 
as  this  will  ensure  that  key  stakeholders,  especially  the  stakeholder,  sponsor,  and  customer  are  interviewed  or 
otherwise  participate  during  the  Identify  Risks  process. 
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11.2.1.10  Project  Documents 

Project  documents  provide  the  project  team  with  information  about  decisions  that  help  better  identify  project 
risks.  Project  documents  improve  cross-team  and  stakeholder  communications  and  include,  but  are  not  limited  to: 

• Project  charter, 

• Project  schedule, 

• Schedule  network  diagrams, 

• Issue  log, 

• Quality  checklist,  and 

• Other  information  proven  to  be  valuable  in  identifying  risks. 


11.2.1.11  Procurement  Documents 


Defined  in  Section  12.1.3.3.  If  the  project  requires  external  procurement  of  resources,  procurement 
documents  become  a key  input  to  the  Identify  Risks  process.  The  complexity  and  the  level  of  detail  of  the 
procurement  documents  should  be  consistent  with  the  value  of,  and  risks  associated  with,  planned  procurement. 


11.2.1.12  Enterprise  Environmental  Factors 

Described  in  Section  2.1.5.  Enterprise  environmental  factors  that  can  influence  the  Identify  Risks  process 
include,  but  are  not  limited  to: 

• Published  information,  including  commercial  databases, 

• Academic  studies, 

• Published  checklists, 

• Benchmarking, 

• Industry  studies,  and 

• Risk  attitudes. 
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11.2.1.13  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  Organizational  process  assets  that  can  influence  the  Identify  Risks  process  include, 
but  are  not  limited  to: 

• Project  files,  including  actual  data, 

• Organizational  and  project  process  controls, 

• Risk  statement  formats  or  templates,  and 

• Lessons  learned. 

11.2.2  Identify  Risks:  Tools  and  Techniques 

11.2.2.1  Documentation  Reviews 

A structured  review  of  the  project  documentation  may  be  performed,  including  plans,  assumptions,  previous 
project  files,  agreements,  and  other  information.  The  quality  of  the  plans,  as  well  as  consistency  between  those 
plans  and  the  project  requirements  and  assumptions,  may  be  indicators  of  risk  in  the  project. 

11.2.2.2  Information  Gathering  Techniques 

Examples  of  information  gathering  techniques  used  in  identifying  risks  can  include: 

• Brainstorming.  The  goal  of  brainstorming  is  to  obtain  a comprehensive  list  of  project  risks.  The  project 
team  usually  performs  brainstorming,  often  with  a multidisciplinary  set  of  experts  who  are  not  part  of  the 
team.  Ideas  about  project  risk  are  generated  under  the  leadership  of  a facilitator,  either  in  a traditional 
free-form  brainstorm  session  or  structured  mass  interviewing  techniques.  Categories  of  risk,  such  as  in  a 
risk  breakdown  structure,  can  be  used  as  a framework.  Risks  are  then  identified  and  categorized  by  type 
of  risk  and  their  definitions  are  refined. 

• Delphi  technique.  The  Delphi  technique  is  a way  to  reach  a consensus  of  experts.  Project  risk  experts 
participate  in  this  technique  anonymously.  A facilitator  uses  a questionnaire  to  solicit  ideas  about  the 
important  project  risks.  The  responses  are  summarized  and  are  then  recirculated  to  the  experts  for 
further  comment.  Consensus  may  be  reached  in  a few  rounds  of  this  process.  The  Delphi  technique  helps 
reduce  bias  in  the  data  and  keeps  any  one  person  from  having  undue  influence  on  the  outcome. 
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• Interviewing.  Interviewing  experienced  project  participants,  stakeholders,  and  subject  matter  experts 
helps  to  identify  risks. 

• Root  cause  analysis.  Root-cause  analysis  is  a specific  technique  used  to  identify  a problem,  discover 
the  underlying  causes  that  lead  to  it,  and  develop  preventive  action. 

1 1 .2.2.3  Checklist  Analysis 

Risk  identification  checklists  are  developed  based  on  historical  information  and  knowledge  that  has  been 
accumulated  from  previous  similar  projects  and  from  other  sources  of  information.  The  lowest  level  of  the  RBS 
can  also  be  used  as  a risk  checklist.  While  a checklist  may  be  quick  and  simple,  it  is  impossible  to  build  an 
exhaustive  one,  and  care  should  be  taken  to  ensure  the  checklist  is  not  used  to  avoid  the  effort  of  proper  risk 
identification.  The  team  should  also  explore  items  that  do  not  appear  on  the  checklist.  Additionally,  the  checklist 
should  be  pruned  from  time  to  time  to  remove  or  archive  related  items.  The  checklist  should  be  reviewed  during 
project  closure  to  incorporate  new  lessons  learned  and  improve  it  for  use  on  future  projects. 


1 1 .2.2.4  Assumptions  Analysis 

Every  project  and  its  plan  is  conceived  and  developed  based  on  a set  of  hypotheses,  scenarios,  or  assumptions. 
Assumptions  analysis  explores  the  validity  of  assumptions  as  they  apply  to  the  project.  It  identifies  risks  to  the 
project  from  inaccuracy,  instability,  inconsistency,  or  incompleteness  of  assumptions. 


11.2.2.5  Diagramming  Techniques 

Risk  diagramming  techniques  may  include: 

• Cause  and  effect  diagrams.  These  are  also  known  as  Ishikawa  or  fishbone  diagrams  and  are  useful  for 
identifying  causes  of  risks. 

• System  or  process  flow  charts.  These  show  how  various  elements  of  a system  interrelate  and  the 
mechanism  of  causation. 

• Influence  diagrams.  These  are  graphical  representations  of  situations  showing  causal  influences,  time 
ordering  of  events,  and  other  relationships  among  variables  and  outcomes,  as  shown  in  Figure  11-7. 
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Figure  11-7.  Influence  Diagram 


11.2.2.6  SWOT  Analysis 

This  technique  examines  the  project  from  each  of  the  strengths,  weaknesses,  opportunities,  and  threats  (SWOT) 
perspectives  to  increase  the  breadth  of  identified  risks  by  including  internally  generated  risks.  The  technique  starts 
with  identification  of  strengths  and  weaknesses  of  the  organization,  focusing  on  either  the  project,  organization, 
or  the  business  area  in  general.  SWOT  analysis  then  identifies  any  opportunities  for  the  project  that  arise  from 
organizational  strengths,  and  any  threats  arising  from  organizational  weaknesses.  The  analysis  also  examines 
the  degree  to  which  organizational  strengths  offset  threats,  as  well  as  identifying  opportunities  that  may  serve  to 
overcome  weaknesses. 
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11.2.2.7  Expert  Judgment 

Risks  may  be  identified  directly  by  experts  with  relevant  experience  with  similar  projects  or  business  areas. 
Such  experts  should  be  identified  by  the  project  manager  and  invited  to  consider  all  aspects  of  the  project  and 
suggest  possible  risks  based  on  their  previous  experience  and  areas  of  expertise.  The  experts’  bias  should  be  taken 
into  account  in  this  process. 

11.2.3  Identify  Risks:  Outputs 

11.2.3.1  Risk  Register 

The  primary  output  from  Identify  Risks  is  the  initial  entry  into  the  risk  register.  The  risk  register  is  a document 
in  which  the  results  of  risk  analysis  and  risk  response  planning  are  recorded.  It  contains  the  outcomes  of  the  other 
risk  management  processes  as  they  are  conducted,  resulting  in  an  increase  in  the  level  and  type  of  information 
contained  in  the  risk  register  over  time.  The  preparation  of  the  risk  register  begins  in  the  Identify  Risks  process 
with  the  following  information,  and  then  becomes  available  to  other  project  management  and  risk  management 
processes: 

• List  of  identified  risks.  The  identified  risks  are  described  in  as  much  detail  as  is  reasonable.  A 
structure  for  describing  risks  using  risk  statements  may  be  applied,  for  example,  EVENT  may  occur 
causing  IMPACT,  or  If  CAUSE  exists,  EVENT  may  occur  leading  to  EFFECT.  In  addition  to  the  list  of 
identified  risks,  the  root  causes  of  those  risks  may  become  more  evident.  These  are  the  fundamental 
conditions  or  events  that  may  give  rise  to  one  or  more  identified  risks.  They  should  be  recorded  and 
used  to  support  future  risk  identification  for  this  and  other  projects. 

• List  of  potential  responses.  Potential  responses  to  a risk  may  sometimes  be  identified  during  the  Identify 
Risks  process.  These  responses,  if  identified  in  this  process,  should  be  used  as  inputs  to  the  Plan  Risk 
Responses  process. 
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11.3  Perform  Qualitative  Risk  Analysis 

Perform  Qualitative  Risk  Analysis  is  the  process  of  prioritizing  risks  for  further  analysis  or  action  by  assessing 
and  combining  their  probability  of  occurrence  and  impact.  The  key  benefit  of  this  process  is  that  it  enables  project 
managers  to  reduce  the  level  of  uncertainty  and  to  focus  on  high-priority  risks.  The  inputs,  tools  and  techniques, 
and  outputs  of  this  process  are  depicted  in  Figure  1 1 -8.  Figure  1 1 -9  depicts  the  data  flow  diagram  of  the  process. 
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Figure  11-8.  Perform  Qualitative  Risk  Analysis:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  11-9.  Perform  Qualitative  Risk  Analysis  Data  Flow  Diagram 
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Perform  Qualitative  Risk  Analysis  assesses  the  priority  of  identified  risks  using  their  relative  probability  or 
likelihood  of  occurrence,  the  corresponding  impact  on  project  objectives  if  the  risks  occur,  as  well  as  other 
factors  such  as  the  time  frame  for  response  and  the  organization’s  risk  tolerance  associated  with  the  project 
constraints  of  cost,  schedule,  scope,  and  quality.  Such  assessments  reflect  the  risk  attitude  of  the  project 
team  and  other  stakeholders.  Effective  assessment  therefore  requires  explicit  identification  and  management 
of  the  risk  approaches  of  key  participants  in  the  Perform  Qualitative  Risk  Analysis  process.  Where  these  risk 
approaches  introduce  bias  into  the  assessment  of  identified  risks,  attention  should  be  paid  to  identifying  bias 
and  correcting  for  it. 

Establishing  definitions  of  the  levels  of  probability  and  impact  can  reduce  the  influence  of  bias.  The  time 
criticality  of  risk-related  actions  may  magnify  the  importance  of  a risk.  An  evaluation  of  the  quality  of  the 
available  information  on  project  risks  also  helps  to  clarify  the  assessment  of  the  risk’s  importance  to  the  project. 

Perform  Qualitative  Risk  Analysis  is  usually  a rapid  and  cost-effective  means  of  establishing  priorities  for  Plan 
Risk  Responses  and  lays  the  foundation  for  Perform  Quantitative  Risk  Analysis,  if  required.  The  Perform  Qualitative 
Risk  Analysis  process  is  performed  regularly  throughout  the  project  life  cycle,  as  defined  in  the  project’s  risk 
management  plan.  This  process  can  lead  into  Perform  Quantitative  Risk  Analysis  (Section  1 1 .4)  or  directly  into  Plan 
Risk  Responses  (Section  1 1 .5). 

11.3.1  Perform  Qualitative  Risk  Analysis:  Inputs 

11.3.1.1  Risk  Management  Plan 

Described  in  Section  1 1 .1 .3.1 . Key  elements  of  the  risk  management  plan  used  in  the  Perform  Qualitative  Risk 
Analysis  process  include  roles  and  responsibilities  for  conducting  risk  management,  budgets,  schedule  activities 
for  risk  management,  risk  categories,  definitions  of  probability  and  impact,  the  probability  and  impact  matrix, 
and  revised  stakeholders’  risk  tolerances.  These  inputs  are  usually  tailored  to  the  project  during  the  Plan  Risk 
Management  process.  If  they  are  not  available,  they  may  be  developed  during  the  Perform  Qualitative  Risk  Analysis 
process. 

11.3.1.2  Scope  Baseline 

Described  in  Section  5.4. 3.1 . Projects  of  a common  or  recurrent  type  tend  to  have  more  well-understood  risks. 
Projects  using  state-of-the-art  or  first-of-its-kind  technology,  and  highly  complex  projects,  tend  to  have  more 
uncertainty.  This  can  be  evaluated  by  examining  the  scope  baseline. 
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11.3.1.3  Risk  Register 

Described  in  Section  1 1 .2.3.1 . The  risk  register  contains  the  information  that  will  be  used  to  assess  and  prioritize 
risks. 

11.3.1.4  Enterprise  Environmental  Factors 

Described  in  Section  2.1.5.  Enterprise  environmental  factors  may  provide  insight  and  context  to  the  risk 
assessment,  such  as: 

• Industry  studies  of  similar  projects  by  risk  specialists,  and 

• Risk  databases  that  may  be  available  from  industry  or  proprietary  sources. 

11.3.1.5  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  can  influence  the  Perform  Qualitative  Risk 
Analysis  process  include  information  on  prior,  similar  completed  projects. 

11.3.2  Perform  Qualitative  Risk  Analysis:  Tools  and  Techniques 

11.3.2.1  Risk  Probability  and  Impact  Assessment 

Risk  probability  assessment  investigates  the  likelihood  that  each  specific  risk  will  occur.  Risk  impact 
assessment  investigates  the  potential  effect  on  a project  objective  such  as  schedule,  cost,  quality,  or  performance, 
including  both  negative  effects  for  threats  and  positive  effects  for  opportunities. 

Probability  and  impact  are  assessed  for  each  identified  risk.  Risks  can  be  assessed  in  interviews  or  meetings 
with  participants  selected  for  their  familiarity  with  the  risk  categories  on  the  agenda.  Project  team  members  and 
knowledgeable  persons  external  to  the  project  are  included. 

The  level  of  probability  for  each  risk  and  its  impact  on  each  objective  is  evaluated  during  the  interview  or  meeting. 
Explanatory  detail,  including  assumptions  justifying  the  levels  assigned,  are  also  recorded.  Risk  probabilities 
and  impacts  are  rated  according  to  the  definitions  given  in  the  risk  management  plan.  Risks  with  low  ratings  of 
probability  and  impact  will  be  included  within  the  risk  register  as  part  of  the  watch  list  for  future  monitoring. 
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11.3.2.2  Probability  and  Impact  Matrix 

Risks  can  be  prioritized  for  further  quantitative  analysis  and  planning  risk  responses  based  on  their  risk  rating. 
Ratings  are  assigned  to  risks  based  on  their  assessed  probability  and  impact.  Evaluation  of  each  risk’s  importance 
and  priority  for  attention  is  typically  conducted  using  a look-up  table  or  a probability  and  impact  matrix.  Such  a 
matrix  specifies  combinations  of  probability  and  impact  that  lead  to  rating  the  risks  as  low,  moderate,  or  high 
priority.  Descriptive  terms  or  numeric  values  can  be  used  depending  on  organizational  preference. 

Each  risk  is  rated  on  its  probability  of  occurrence  and  impact  on  an  objective  if  it  does  occur.  The  organization 
should  determine  which  combinations  of  probability  and  impact  result  in  a classification  of  high  risk,  moderate  risk, 
and  low  risk.  In  a black-and-white  matrix,  these  conditions  are  denoted  using  different  shades  of  gray.  Specifically 
in  Figure  11-10,  the  dark  gray  area  (with  the  largest  numbers)  represents  high  risk:  the  medium  gray  area  (with 
the  smallest  numbers)  represents  low  risk,  and  the  light  gray  area  (with  in-between  numbers)  represents  moderate 
risk.  Usually,  these  risk-rating  rules  are  specified  by  the  organization  in  advance  of  the  project  and  included  in 
organizational  process  assets.  Risk  rating  rules  can  be  tailored  in  the  Plan  Risk  Management  process  to  the  specific 
project. 
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Each  risk  is  rated  on  its  probability  of  occurring  and  impact  on  an  objective  if  it  does  occur.  The  organization's 
thresholds  for  low,  moderate  or  high  risks  are  shown  in  the  matrix  and  determine  whether  the  risk  is  scored 
as  high,  moderate  or  low  for  that  objective. 


Figure  11-10.  Probability  and  Impact  Matrix 
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As  illustrated  in  Figure  11-10,  an  organization  can  rate  a risk  separately  for  each  objective  (e.g.,  cost,  time, 
and  scope).  In  addition,  it  may  develop  ways  to  determine  one  overall  rating  for  each  risk.  Finally,  opportunities 
and  threats  are  handled  in  the  same  matrix  using  definitions  of  the  different  levels  of  impact  that  are  appropriate 
for  each. 

The  risk  score  helps  guide  risk  responses.  For  example,  risks  that  have  a negative  impact  on  objectives, 
otherwise  known  as  threats  if  they  occur,  and  that  are  in  the  high-risk  (dark  gray)  zone  of  the  matrix,  may  require 
priority  action  and  aggressive  response  strategies.  Threats  found  in  the  low-risk  (medium  gray)  zone  may  not 
require  proactive  management  action  beyond  being  placed  in  the  risk  register  as  part  of  the  watch  list  or  adding 
a contingency  reserve.  Similarly  for  opportunities,  those  in  the  high-risk  (dark  gray)  zone,  which  may  be  obtained 
most  easily  and  offer  the  greatest  benefit,  should  be  targeted  first.  Opportunities  in  the  low-risk  (medium  gray)  zone 
should  be  monitored. 

11.3.2.3  Risk  Data  Quality  Assessment 

Risk  data  quality  assessment  is  a technique  to  evaluate  the  degree  to  which  the  data  about  risks  is  useful 
for  risk  management.  It  involves  examining  the  degree  to  which  the  risk  is  understood  and  the  accuracy,  quality, 
reliability,  and  integrity  of  the  data  about  the  risk. 

The  use  of  low-quality  risk  data  may  lead  to  a qualitative  risk  analysis  of  little  use  to  the  project.  If  data  quality  is 
unacceptable,  it  may  be  necessary  to  gather  better  data.  Often,  the  collection  of  information  about  risks  is  difficult, 
and  consumes  more  time  and  resources  than  originally  planned.  The  values  used  in  the  example  in  Figure  11-10 
are  representative.  The  numbers  of  steps  in  the  scale  are  usually  established  when  defining  the  risk  attitude  of  the 
organization. 

11.3.2.4  Risk  Categorization 

Risks  to  the  project  can  be  categorized  by  sources  of  risk  (e.g.,  using  the  RBS),  the  area  of  the  project  affected 
(e.g.,  using  the  WBS),  or  other  useful  categories  (e.g.,  project  phase)  to  determine  the  areas  of  the  project  most 
exposed  to  the  effects  of  uncertainty.  Risks  can  also  be  categorized  by  common  root  causes.  This  technique  helps 
determine  work  packages,  activities,  project  phases  or  even  roles  in  the  project,  which  can  lead  to  the  development 
of  effective  risk  responses. 
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1 1 .3.2.5  Risk  Urgency  Assessment 

Risks  requiring  near-term  responses  may  be  considered  more  urgent  to  address.  Indicators  of  priority  may 
include  probability  of  detecting  the  risk,  time  to  affect  a risk  response,  symptoms  and  warning  signs,  and  the 
risk  rating.  In  some  qualitative  analyses,  the  assessment  of  risk  urgency  is  combined  with  the  risk  ranking  that  is 
determined  from  the  probability  and  impact  matrix  to  give  a final  risk  severity  rating. 

11.3.2.6  Expert  Judgment 

Expert  judgment  is  required  to  assess  the  probability  and  impact  of  each  risk  to  determine  its  location  in 
the  matrix  shown  in  Figure  11-10.  Experts  generally  are  those  having  experience  with  similar,  recent  projects. 
Gathering  expert  judgment  is  often  accomplished  with  the  use  of  risk  facilitation  workshops  or  interviews.  The 
experts’  bias  should  be  taken  into  account  in  this  process. 


11.3.3  Perform  Qualitative  Risk  Analysis:  Outputs 

11.3.3.1  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Risk  register  updates.  As  new  information  becomes  available  through  the  qualitative  risk 
assessment,  the  risk  register  is  updated.  Updates  to  the  risk  register  may  include  assessments 
of  probability  and  impacts  for  each  risk,  risk  ranking  or  scores,  risk  urgency  information  or  risk 
categorization,  and  a watch  list  for  low  probability  risks  or  risks  requiring  further  analysis. 

• Assumptions  log  updates.  As  new  information  becomes  available  through  the  qualitative  risk 
assessment,  assumptions  could  change.  The  assumptions  log  needs  to  be  revisited  to  accommodate 
this  new  information.  Assumptions  may  be  incorporated  into  the  project  scope  statement  or  in  a 
separate  assumptions  log. 


11.4  Perform  Quantitative  Risk  Analysis 

Perform  Quantitative  Risk  Analysis  is  the  process  of  numerically  analyzing  the  effect  of  identified  risks  on  overall 
project  objectives.  The  key  benefit  of  this  process  is  that  it  produces  quantitative  risk  information  to  support  decision 
making  in  order  to  reduce  project  uncertainty.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are 
depicted  in  Figure  11-11.  Figure  11-12  depicts  the  data  flow  diagram  of  the  process. 
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Inputs 


.1  Risk  management  plan 
.2  Cost  management  plan 
.3  Schedule  management 
plan 

.4  Risk  register 
.5  Enterprise  environmental 
factors 

.6  Organizational  process 
assets 

V / 


Tools  & Techniques 


.1  Data  gathering  and 
representation 
techniques 

.2  Quantitative  risk  analysis 
and  modeling  techniques 
.3  Expert  judgment 

V / 


Outputs 


.1  Project  documents 
updates 

V / 


Figure  11-11.  Perform  Quantitative  Risk  Analysis:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  11-12.  Perform  Quantitative  Risk  Analysis  Data  Flow  Diagram 


Perform  Quantitative  Risk  Analysis  is  performed  on  risks  that  have  been  prioritized  by  the  Perform  Qualitative 
Risk  Analysis  process  as  potentially  and  substantially  impacting  the  project’s  competing  demands.  The  Perform 
Quantitative  Risk  Analysis  process  analyzes  the  effect  of  those  risks  on  project  objectives.  It  is  used  mostly  to 
evaluate  the  aggregate  effect  of  all  risks  affecting  the  project.  When  the  risks  drive  the  quantitative  analysis,  the 
process  may  be  used  to  assign  a numerical  priority  rating  to  those  risks  individually. 
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Perform  Quantitative  Risk  Analysis  generally  follows  the  Perform  Qualitative  Risk  Analysis  process.  In  some 
cases,  it  may  not  be  possible  to  execute  the  Perform  Quantitative  Risk  Analysis  process  due  to  lack  of  sufficient 
data  to  develop  appropriate  models.  The  project  manager  should  exercise  expert  judgment  to  determine  the  need 
for  and  the  viability  of  quantitative  risk  analysis.  The  availability  of  time  and  budget,  and  the  need  for  qualitative  or 
quantitative  statements  about  risk  and  impacts,  will  determine  which  method(s)  to  use  on  any  particular  project. 

Perform  Quantitative  Risk  Analysis  should  be  repeated,  as  needed,  as  part  of  the  Control  Risks  process  to  determine 
if  the  overall  project  risk  has  been  satisfactorily  decreased.  Trends  may  indicate  the  need  for  more  or  less  focus  on 
appropriate  risk  management  activities. 

11.4.1  Perform  Quantitative  Risk  Analysis:  Inputs 

11.4.1.1  Risk  Management  Plan 

Described  in  Section  1 1 .1 .3.1 . The  risk  management  plan  provides  guidelines,  methods,  and  tools  to  be  used  in 
quantitative  risk  analysis. 

11 

11.4.1.2  Cost  Management  Plan 

Described  in  Section  7.1 .3.1  .The  cost  management  plan  provides  guidelines  on  establishing  and  managing  risk 
reserves. 

1 1 .4.1 .3  Schedule  Management  Plan 

Described  in  Section  6.1 .3.1  .The  schedule  management  plan  provides  guidelines  on  establishing  and  managing 
risk  reserves. 

11.4.1.4  Risk  Register 

Described  in  Section  11.2.3.1.  The  risk  register  is  used  as  a reference  point  for  performing  quantitative  risk 
analysis. 

11.4.1.5  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  Enterprise  environmental  factors  may  provide  insight  and  context  to  the  risk  analysis, 
such  as: 


• Industry  studies  of  similar  projects  by  risk  specialists,  and 

• Risk  databases  that  may  be  available  from  industry  or  proprietary  sources. 
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1 1 .4.1 .6  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  organizational  process  assets  that  can  influence  the  Perform  Quantitative  Risk 

Analysis  process  include  information  from  prior,  similar  completed  projects. 

11.4.2  Perform  Quantitative  Risk  Analysis:  Tools  and  Techniques 

11.4.2.1  Data  Gathering  and  Representation  Techniques 

• Interviewing.  Interviewing  techniques  draw  on  experience  and  historical  data  to  quantify  the  probability 
and  impact  of  risks  on  project  objectives.  The  information  needed  depends  upon  the  type  of  probability 
distributions  that  will  be  used.  For  instance,  information  would  be  gathered  on  the  optimistic  (low), 
pessimistic  (high),  and  most  likely  scenarios  for  some  commonly  used  distributions.  Examples  of  three- 
point  estimates  for  cost  are  shown  in  Figure  11-13.  Additional  information  on  three-point  estimates 
appears  in  Estimate  Activity  Durations  (Section  6.5)  and  Estimate  Costs  (Section  7.2).  Documenting  the 
rationale  of  the  risk  ranges  and  the  assumptions  behind  them  are  important  components  of  the  risk 
interview  because  they  can  provide  insight  on  the  reliability  and  credibility  of  the  analysis. 


Range  of  Project  Cost  Estimates 


WBS  Element 

Low 

Most  Likely 

High 

Design 

$4M 

$6M 

$10  M 

Build 

$16M 

$20  M 

$35  M 

Test 

$11 M 

$15  M 

$23  M 

Total  Project 

$31 M 

$41 M 

$68M 

Interviewing  relevant  stakeholders  helps  determine  the  three-point  estimates  for  each  WBS 
element  for  triangular,  beta  or  other  distributions.  In  this  example,  the  likelihood  of  completing 
the  project  at  or  below  the  most  likely  estimate  of  $41  million  is  relatively  small  as  shown  in 
the  simulation  results  in  Figure  11-17  (Cost  Risk  Simulation  Results). 


Figure  11-13.  Range  of  Project  Cost  Estimates  Collected  During  the  Risk  Interview 
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• Probability  distributions.  Continuous  probability  distributions,  which  are  used  extensively  in  modeling 
and  simulation,  represent  the  uncertainty  in  values  such  as  durations  of  schedule  activities  and  costs 
of  project  components.  Discrete  distributions  can  be  used  to  represent  uncertain  events,  such  as  the 
outcome  of  a test  or  a possible  scenario  in  a decision  tree.  Two  examples  of  widely  used  continuous 
distributions  are  shown  in  Figure  11-14.  These  distributions  depict  shapes  that  are  compatible  with  the 
data  typically  developed  during  the  quantitative  risk  analysis.  Uniform  distributions  can  be  used  if  there 
is  no  obvious  value  that  is  more  likely  than  any  other  between  specified  high  and  low  bounds,  such  as  in 
the  early  concept  stage  of  design. 


Beta  Distribution  Triangular  Distribution 


Beta  and  triangular  distributions  are  frequently  used  in  quantitative  risk  analysis.  The  data  shown  in  the  figure 
on  the  left  (Beta  Distribution)  is  one  example  of  a family  of  such  distributions  determined  by  two  "shape 
parameters”.  Other  commonly  used  distributions  include  the  uniform,  normal  and  lognormal.  In  these  charts 
the  horizontal  (X)  axes  represent  possible  values  of  time  or  cost  and  the  vertical  (Y)  axes  represent  relative 
likelihood. 


Figure  11-14.  Examples  of  Commonly  Used  Probability  Distributions 
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11.4.2.2  Quantitative  Risk  Analysis  and  Modeling  Techniques 

Commonly  used  techniques  use  both  event-oriented  and  project-oriented  analysis  approaches,  including: 

• Sensitivity  analysis.  Sensitivity  analysis  helps  to  determine  which  risks  have  the  most  potential 
impact  on  the  project.  It  helps  to  understand  how  the  variations  in  project’s  objectives  correlate  with 
variations  in  different  uncertainties.  Conversely,  it  examines  the  extent  to  which  the  uncertainty  of 
each  project  element  affects  the  objective  being  studied  when  all  other  uncertain  elements  are  held  at 
their  baseline  values.  One  typical  display  of  sensitivity  analysis  is  the  tornado  diagram  (Figure  11-15), 
which  is  useful  for  comparing  relative  importance  and  impact  of  variables  that  have  a high  degree  of 
uncertainty  to  those  that  are  more  stable.  The  Tornado  diagram  is  also  helpful  in  analyzing  risk-taking 
scenarios  enabled  on  specific  risks  whose  quantitative  analysis  highlights  possible  benefits  greater 
than  corresponding  identified  negative  impacts.  A tornado  diagram  is  a special  type  of  bar  chart  used 
in  sensitivity  analysis  for  comparing  the  relative  importance  of  the  variables.  In  a tornado  diagram, 
the  Y-axis  contains  each  type  of  uncertainty  at  base  values,  and  the  X-axis  contains  the  spread  or 
correlation  of  the  uncertainty  to  the  studied  output.  In  this  figure,  each  uncertainty  contains  a horizontal 
bar  and  is  ordered  vertically  to  show  uncertainties  with  a decreasing  spread  from  the  base  values. 


Figure  11-15.  Example  of  Tornado  Diagram 
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• Expected  monetary  value  analysis.  Expected  monetary  value  (EMV)  analysis  is  a statistical  concept 
that  calculates  the  average  outcome  when  the  future  includes  scenarios  that  may  or  may  not  happen 
(i.e.,  analysis  under  uncertainty).  The  EMV  of  opportunities  are  generally  expressed  as  positive  values, 
while  those  of  threats  are  expressed  as  negative  values.  EMV  requires  a risk-neutral  assumption — 
neither  risk  averse  nor  risk  seeking.  EMV  for  a project  is  calculated  by  multiplying  the  value  of  each 
possible  outcome  by  its  probability  of  occurrence  and  adding  the  products  together.  A common  use  of 
this  type  of  analysis  is  a decision  tree  analysis  (Figure  1 1 -1 6). 


Decision  Definition 

Decision  Node 

Chance  Node 

Net  Path  Value 

Decision  to 
be  Made 

Input:  Cost  of  Each  Decision 

Output:  Decision  Made 

Input:  Scenario  Probability, 

Reward  if  it  Occurs 

Output:  Expected  Monetary 

Value  (EMV) 

Computed: 

Payoffs  minus  Costs 
along  Path 

Note  1:  The  decision  tree  shows  how  to  make  a decision  between  alternative  capital  strategies  (represented  as  “decision 
nodes”)  when  the  environment  contains  uncertain  elements  (represented  as  “chance  nodes”). 

Note  2:  Here,  a decision  is  being  made  whether  to  invest  $120M  US  to  build  a new  plant  or  to  instead  invest  only  $50M  US 
to  upgrade  the  existing  plant.  For  each  decision,  the  demand  (which  is  uncertain,  and  therefore  represents  a 
“chance  node")  must  be  accounted  for.  For  example,  strong  demand  leads  to  $200M  revenue  with  the  new  plant 
but  only  $120M  US  for  the  upgraded  plant,  perhaps  due  to  capacity  limitations  of  the  upgraded  plant.  The  end  of 
each  branch  shows  the  net  effect  of  the  payoffs  minus  costs.  For  each  decision  branch,  all  effects  are  added  (see 
shaded  areas)  to  determine  the  overall  Expected  Monetary  Value  (EMV)  of  the  decision.  Remember  to  account  for 
the  investment  costs.  From  the  calculations  in  the  shaded  areas,  the  upgraded  plant  has  a higher  EMV  of  $46M  - 
also  the  EMV  of  the  overall  decision.  (This  choice  also  represents  the  lowest  risk,  avoiding  the  worst  case  possible 
outcome  of  a loss  of  $30M). 


Figure  11-16.  Decision  Tree  Diagram 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK®  Guide)  - Fifth  Edition 


339 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


11  - PROJECT  RISK  MANAGEMENT 


• Modeling  and  simulation.  A project  simulation  uses  a model  that  translates  the  specified  detailed 
uncertainties  of  the  project  into  their  potential  impact  on  project  objectives.  Simulations  are  typically 
performed  using  the  Monte  Carlo  technique.  In  a simulation,  the  project  model  is  computed  many  times 
(iterated),  with  the  input  values  (e.g.,  cost  estimates  or  activity  durations)  chosen  at  random  for  each 
iteration  from  the  probability  distributions  of  these  variables.  A histogram  (e.g.,  total  cost  or  completion 
date)  is  calculated  from  the  iterations.  For  a cost  risk  analysis,  a simulation  uses  cost  estimates.  For  a 
schedule  risk  analysis,  the  schedule  network  diagram  and  duration  estimates  are  used.  The  output  from  a 
cost  risk  simulation  using  the  three-element  model  and  risk  ranges  is  shown  in  Figure  11-17.  It  illustrates 
the  respective  probability  of  achieving  specific  cost  targets.  Similar  curves  can  be  developed  for  other 
project  objectives. 


Total  Project  Cost 

Cumulative  Chart 


This  cumulative  distribution,  assuming  the  data  ranges  in  Figure  11-13  and  triangular  distributions,  shows  that  the 
project  is  only  12  percent  likely  to  meet  the  $41  million  most  likely  cost  estimate.  If  a conservative  organization  wants 
a 75%  likelihood  of  success,  a budget  of  $50  million  (a  contingency  of  nearly  22  % ($50M  - $41M)/$41M))  is  required. 


Figure  11-17.  Cost  Risk  Simulation  Results 
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11.4.2.3  Expert  Judgment 

Expert  judgment  (ideally  using  experts  with  relevant,  recent  experience)  is  required  to  identify  potential  cost 
and  schedule  impacts,  to  evaluate  probability,  and  to  define  inputs  such  as  probability  distributions  into  the  tools. 

Expert  judgment  also  comes  into  play  in  the  interpretation  of  the  data.  Experts  should  be  able  to  identify  the 
weaknesses  of  the  tools  as  well  as  their  strengths.  Experts  may  determine  when  a specific  tool  may  or  may  not  be 
more  appropriate  given  the  organization’s  capabilities  and  culture. 


1 1 .4.3  Perform  Quantitative  Risk  Analysis:  Outputs 


11.4.3.1  Project  Documents  Updates 

Project  documents  are  updated  with  information  resulting  from  quantitative  risk  analysis.  For  example,  risk 
register  updates  could  include: 

• Probabilistic  analysis  of  the  project.  Estimates  are  made  of  potential  project  schedule  and  cost 
outcomes  listing  the  possible  completion  dates  and  costs  with  their  associated  confidence  levels. 
This  output,  often  expressed  as  a cumulative  frequency  distribution,  is  used  with  stakeholder  risk 
tolerances  to  permit  quantification  of  the  cost  and  time  contingency  reserves.  Such  contingency 
reserves  are  needed  to  bring  the  risk  of  overrunning  stated  project  objectives  to  a level  acceptable  to 
the  organization. 

• Probability  of  achieving  cost  and  time  objectives.  With  the  risks  facing  the  project,  the  probability 
of  achieving  project  objectives  under  the  current  plan  can  be  estimated  using  quantitative  risk  analysis 
results.  For  instance,  in  Figure  11-17,  the  likelihood  of  achieving  the  cost  estimate  of  US$41  million  is 
about  12%. 

• Prioritized  list  of  quantified  risks.  This  list  includes  those  risks  that  pose  the  greatest  threat  or  present 
the  greatest  opportunity  to  the  project.  These  include  the  risks  that  may  have  the  greatest  effect  on  cost 
contingency  and  those  that  are  most  likely  to  influence  the  critical  path.  These  risks  may  be  evaluated,  in 
some  cases,  through  a tornado  diagram  generated  as  a result  of  the  simulation  analysis. 

• Trends  in  quantitative  risk  analysis  results.  As  the  analysis  is  repeated,  a trend  may  become  apparent 
that  leads  to  conclusions  affecting  risk  responses.  Organizational  historical  information  on  project  schedule, 
cost,  quality,  and  performance  should  reflect  new  insights  gained  through  the  Perform  Quantitative  Risk 
Analysis  process.  Such  history  may  take  the  form  of  a quantitative  risk  analysis  report.  This  report  may 
be  separate  from,  or  linked  to,  the  risk  register. 
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11.5  Plan  Risk  Responses 

Plan  Risk  Responses  is  the  process  of  developing  options  and  actions  to  enhance  opportunities  and  to  reduce 
threats  to  project  objectives.  The  key  benefit  of  this  process  is  that  it  addresses  the  risks  by  their  priority,  inserting 
resources  and  activities  into  the  budget,  schedule  and  project  management  plan  as  needed.  The  inputs,  tools  and 
techniques,  and  outputs  of  this  process  are  depicted  in  Figure  11-18.  Figure  11-19  depicts  the  data  flow  diagram 
of  the  process. 
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Figure  11-18.  Plan  Risk  Responses:  Inputs,  Tools  & Techniques,  and  Outputs 
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The  Plan  Risk  Responses  process  follows  the  Perform  Quantitative  Risk  Analysis  process  (if  used).  Each  risk 
response  requires  an  understanding  of  the  mechanism  by  which  it  will  address  the  risk.  This  is  the  mechanism 
used  to  analyze  if  the  risk  response  plan  is  having  the  desired  effect.  It  includes  the  identification  and  assignment 
of  one  person  (an  owner  for  risk  response)  to  take  responsibility  for  each  agreed-to  and  funded  risk  response.  Risk 
responses  should  be  appropriate  for  the  significance  of  the  risk,  cost-effective  in  meeting  the  challenge,  realistic 
within  the  project  context,  agreed  upon  by  all  parties  involved,  and  owned  by  a responsible  person.  Selecting  the 
optimum  risk  response  from  several  options  is  often  required. 

The  Plan  Risk  Responses  process  presents  commonly  used  approaches  to  planning  responses  to  the  risks. 
Risks  include  threats  and  opportunities  that  can  affect  project  success,  and  responses  are  discussed  for  each. 


11.5.1  Plan  Risk  Responses:  Inputs 


11.5.1.1  Risk  Management  Plan 

Important  components  of  the  risk  management  plan  include  roles  and  responsibilities,  risk  analysis  definitions, 
timing  for  reviews  (and  for  eliminating  risks  from  review),  and  risk  thresholds  for  low,  moderate,  and  high  risks.  Risk 
thresholds  help  identify  those  risks  for  which  specific  responses  are  needed. 


11.5.1.2  Risk  Register 

The  risk  register  refers  to  identified  risks,  root  causes  of  risks,  lists  of  potential  responses,  risk  owners,  symptoms 
and  warning  signs,  the  relative  rating  or  priority  list  of  project  risks,  risks  requiring  responses  in  the  near  term,  risks 
for  additional  analysis  and  response,  trends  in  qualitative  analysis  results,  and  a watch  list,  which  is  a list  of  low- 
priority  risks  within  the  risk  register. 


11.5.2  Plan  Risk  Responses:  Tools  and  Techniques 

Several  risk  response  strategies  are  available.  The  strategy  or  mix  of  strategies  most  likely  to  be  effective 
should  be  selected  for  each  risk.  Risk  analysis  tools,  such  as  decision  tree  analysis  (Section  11.4.2.2),  can  be 
used  to  choose  the  most  appropriate  responses.  Specific  actions  are  developed  to  implement  that  strategy, 
including  primary  and  backup  strategies,  as  necessary.  A fallback  plan  can  be  developed  for  implementation 
if  the  selected  strategy  turns  out  not  to  be  fully  effective  or  if  an  accepted  risk  occurs.  Secondary  risks  should 
also  be  reviewed.  Secondary  risks  are  risks  that  arise  as  a direct  result  of  implementing  a risk  response.  A 
contingency  reserve  is  often  allocated  for  time  or  cost.  If  developed,  it  may  include  identification  of  the  conditions 
that  trigger  its  use. 
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11.5.2.1  Strategies  for  Negative  Risks  or  Threats 

Three  strategies,  which  typically  deal  with  threats  or  risks  that  may  have  negative  impacts  on  project  objectives 
if  they  occur,  are:  avoid,  transfer,  and  mitigate.  The  fourth  strategy,  accept,  can  be  used  for  negative  risks  or  threats 
as  well  as  positive  risks  or  opportunities.  Each  of  these  risk  response  strategies  have  varied  and  unique  influence 
on  the  risk  condition.  These  strategies  should  be  chosen  to  match  the  risk’s  probability  and  impact  on  the  project’s 
overall  objectives.  Avoidance  and  mitigation  strategies  are  usually  good  strategies  for  critical  risks  with  high  impact, 
while  transference  and  acceptance  are  usually  good  strategies  for  threats  that  are  less  critical  and  with  low  overall 
impact.  The  four  strategies  for  dealing  with  negative  risks  or  threats  are  further  described  as  follows: 

• Avoid.  Risk  avoidance  is  a risk  response  strategy  whereby  the  project  team  acts  to  eliminate  the  threat  or 
protect  the  project  from  its  impact.  It  usually  involves  changing  the  project  management  plan  to  eliminate 
the  threat  entirely.  The  project  manager  may  also  isolate  the  project  objectives  from  the  risk’s  impact  or 
change  the  objective  that  is  in  jeopardy.  Examples  of  this  include  extending  the  schedule,  changing  the 
strategy,  or  reducing  scope.  The  most  radical  avoidance  strategy  is  to  shut  down  the  project  entirely. 
Some  risks  that  arise  early  in  the  project  can  be  avoided  by  clarifying  requirements,  obtaining  information, 
improving  communication,  or  acquiring  expertise. 

• Transfer.  Risk  transference  is  a risk  response  strategy  whereby  the  project  team  shifts  the  impact  of 
a threat  to  a third  party,  together  with  ownership  of  the  response.  Transferring  the  risk  simply  gives 
another  party  responsibility  for  its  management — it  does  not  eliminate  it.  Transferring  does  not  mean 
disowning  the  risk  by  transferring  it  to  a later  project  or  another  person  without  his  or  her  knowledge  or 
agreement.  Risk  transference  nearly  always  involves  payment  of  a risk  premium  to  the  party  taking  on 
the  risk.  Transferring  liability  for  risk  is  most  effective  in  dealing  with  financial  risk  exposure.  Transference 
tools  can  be  quite  diverse  and  include,  but  are  not  limited  to,  the  use  of  insurance,  performance  bonds, 
warranties,  guarantees,  etc.  Contracts  or  agreements  may  be  used  to  transfer  liability  for  specified  risks 
to  another  party.  For  example,  when  a buyer  has  capabilities  that  the  seller  does  not  possess,  it  may  be 
prudent  to  transfer  some  work  and  its  concurrent  risk  contractually  back  to  the  buyer.  In  many  cases,  use 
of  a cost-plus  contract  may  transfer  the  cost  risk  to  the  buyer,  while  a fixed-price  contract  may  transfer 
risk  to  the  seller. 
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• Mitigate.  Risk  mitigation  is  a risk  response  strategy  whereby  the  project  team  acts  to  reduce  the 
probability  of  occurrence  or  impact  of  a risk.  It  implies  a reduction  in  the  probability  and/or  impact  of  an 
adverse  risk  to  be  within  acceptable  threshold  limits.  Taking  early  action  to  reduce  the  probability  and/or 
impact  of  a risk  occurring  on  the  project  is  often  more  effective  than  trying  to  repair  the  damage  after  the 
risk  has  occurred.  Adopting  less  complex  processes,  conducting  more  tests,  or  choosing  a more  stable 
supplier  are  examples  of  mitigation  actions.  Mitigation  may  require  prototype  development  to  reduce  the 
risk  of  scaling  up  from  a bench-scale  model  of  a process  or  product.  Where  it  is  not  possible  to  reduce 
probability,  a mitigation  response  might  address  the  risk  impact  by  targeting  linkages  that  determine  the 
severity.  For  example,  designing  redundancy  into  a system  may  reduce  the  impact  from  a failure  of  the 
original  component. 

• Accept.  Risk  acceptance  is  a risk  response  strategy  whereby  the  project  team  decides  to  acknowledge 
the  risk  and  not  take  any  action  unless  the  risk  occurs.  This  strategy  is  adopted  where  it  is  not  possible 
or  cost-effective  to  address  a specific  risk  in  any  other  way.  This  strategy  indicates  that  the  project 
team  has  decided  not  to  change  the  project  management  plan  to  deal  with  a risk,  or  is  unable  to  identify 
any  other  suitable  response  strategy.  This  strategy  can  be  either  passive  or  active.  Passive  acceptance 
requires  no  action  except  to  document  the  strategy,  leaving  the  project  team  to  deal  with  the  risks  as 
they  occur,  and  to  periodically  review  the  threat  to  ensure  that  it  does  not  change  significantly.  The 
most  common  active  acceptance  strategy  is  to  establish  a contingency  reserve,  including  amounts  of 
time,  money,  or  resources  to  handle  the  risks. 


11.5.2.2  Strategies  for  Positive  Risks  or  Opportunities 

Three  of  the  four  responses  are  suggested  to  deal  with  risks  with  potentially  positive  impacts  on  project  objectives. 
The  fourth  strategy,  accept,  can  be  used  for  negative  risks  or  threats  as  well  as  positive  risks  or  opportunities.  These 
strategies,  described  below,  are  to  exploit,  share,  enhance,  and  accept. 

• Exploit.  The  exploit  strategy  may  be  selected  for  risks  with  positive  impacts  where  the  organization  wishes 
to  ensure  that  the  opportunity  is  realized.  This  strategy  seeks  to  eliminate  the  uncertainty  associated  with 
a particular  upside  risk  by  ensuring  the  opportunity  definitely  happens.  Examples  of  directly  exploiting 
responses  include  assigning  an  organization’s  most  talented  resources  to  the  project  to  reduce  the  time 
to  completion  or  using  new  technologies  or  technology  upgrades  to  reduce  cost  and  duration  required  to 
realize  project  objectives. 
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• Enhance.  The  enhance  strategy  is  used  to  increase  the  probability  and/or  the  positive  impacts  of  an 
opportunity.  Identifying  and  maximizing  key  drivers  of  these  positive-impact  risks  may  increase  the 
probability  of  their  occurrence.  Examples  of  enhancing  opportunities  include  adding  more  resources  to 
an  activity  to  finish  early. 

• Share.  Sharing  a positive  risk  involves  allocating  some  or  all  of  the  ownership  of  the  opportunity  to  a 
third  party  who  is  best  able  to  capture  the  opportunity  for  the  benefit  of  the  project.  Examples  of  sharing 
actions  include  forming  risk-sharing  partnerships,  teams,  special-purpose  companies,  or  joint  ventures, 
which  can  be  established  with  the  express  purpose  of  taking  advantage  of  the  opportunity  so  that  all 
parties  gain  from  their  actions. 

• Accept.  Accepting  an  opportunity  is  being  willing  to  take  advantage  of  the  opportunity  if  it  arises,  but 
not  actively  pursuing  it. 

11.5.2.3  Contingent  Response  Strategies 

Some  responses  are  designed  for  use  only  if  certain  events  occur.  For  some  risks,  it  is  appropriate  for 
the  project  team  to  make  a response  plan  that  will  only  be  executed  under  certain  predefined  conditions,  if 
it  is  believed  that  there  will  be  sufficient  warning  to  implement  the  plan.  Events  that  trigger  the  contingency 
response,  such  as  missing  intermediate  milestones  or  gaining  higher  priority  with  a supplier,  should  be  defined 
and  tracked.  Risk  responses  identified  using  this  technique  are  often  called  contingency  plans  or  fallback  plans 
and  include  identified  triggering  events  that  set  the  plans  in  effect. 

11.5.2.4  Expert  Judgment 

Expert  judgment  is  input  from  knowledgeable  parties  pertaining  to  the  actions  to  be  taken  on  a specific  and 
defined  risk.  Expertise  may  be  provided  by  any  group  or  person  with  specialized  education,  knowledge,  skill, 
experience,  or  training  in  establishing  risk  responses. 

11.5.3  Plan  Risk  Responses:  Outputs 
11.5.3.1  Project  Management  Plan  Updates 

Elements  of  the  project  management  plan  that  may  be  updated  as  a result  of  carrying  out  this  process  include, 
but  are  not  limited  to: 
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• Schedule  management  plan.  The  schedule  management  plan  is  updated  to  reflect  changes  in  process 
and  practice  driven  by  the  risk  responses.  This  may  include  changes  in  tolerance  or  behavior  related  to 
resource  loading  and  leveling,  as  well  as  updates  to  the  schedule  strategy. 

• Cost  management  plan.  The  cost  management  plan  is  updated  to  reflect  changes  in  process  and 
practice  driven  by  the  risk  responses.  This  may  include  changes  in  tolerance  or  behavior  related  to 
cost  accounting,  tracking,  and  reports,  as  well  as  updates  to  the  budget  strategy  and  how  contingency 
reserves  are  consumed. 

• Quality  management  plan.  The  quality  management  plan  is  updated  to  reflect  changes  in  process 
and  practice  driven  by  the  risk  responses.  This  may  include  changes  in  tolerance  or  behavior  related  to 
requirements,  quality  assurance,  or  quality  control,  as  well  as  updates  to  the  requirements  documentation. 

• Procurement  management  plan.  The  procurement  management  plan  may  be  updated  to  reflect 
changes  in  strategy,  such  as  alterations  in  the  make-or-buy  decision  or  contract  type(s)  driven  by  the  risk 
responses. 

• Human  resource  management  plan.  The  staffing  management  plan,  part  of  the  human  resource 
management  plan,  is  updated  to  reflect  changes  in  project  organizational  structure  and  resource 
applications  driven  by  the  risk  responses.  This  may  include  changes  in  tolerance  or  behavior  related  to 
staff  allocation,  as  well  as  updates  to  the  resource  loading. 

• Scope  baseline.  Because  of  new,  modified  or  omitted  work  generated  by  the  risk  responses,  the  scope 
baseline  may  be  updated  to  reflect  those  changes. 

• Schedule  baseline.  Because  of  new  work  (or  omitted  work)  generated  by  the  risk  responses,  the  schedule 
baseline  may  be  updated  to  reflect  those  changes. 

• Cost  baseline.  Because  of  new  work  (or  omitted  work)  generated  by  the  risk  responses,  the  cost  baseline 
may  be  updated  to  reflect  those  changes. 


11.5.3.2  Project  Documents  Updates 

In  the  Plan  Risk  Responses  process,  several  project  documents  are  updated  as  needed.  For  example,  when 
appropriate  risk  responses  are  chosen  and  agreed  upon,  they  are  included  in  the  risk  register.  The  risk  register 
should  be  written  to  a level  of  detail  that  corresponds  with  the  priority  ranking  and  the  planned  response.  Often,  the 
high  and  moderate  risks  are  addressed  in  detail.  Risks  judged  to  be  of  low  priority  are  included  in  a watch  list  for 
periodic  monitoring.  Updates  to  the  risk  register  can  include,  but  are  not  limited  to: 
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• Risk  owners  and  assigned  responsibilities; 

• Agreed-upon  response  strategies; 

• Specific  actions  to  implement  the  chosen  response  strategy; 

• Trigger  conditions,  symptoms,  and  warning  signs  of  a risk  occurrence; 

• Budget  and  schedule  activities  required  to  implement  the  chosen  responses; 

• Contingency  plans  and  triggers  that  call  for  their  execution; 

• Fallback  plans  for  use  as  a reaction  to  a risk  that  has  occurred  and  the  primary  response  proves  to  be 
inadequate; 

• Residual  risks  that  are  expected  to  remain  after  planned  responses  have  been  taken,  as  well  as  those  that 
have  been  deliberately  accepted; 

• Secondary  risks  that  arise  as  a direct  outcome  of  implementing  a risk  response;  and 

• Contingency  reserves  that  are  calculated  based  on  the  quantitative  risk  analysis  of  the  project  and  the 
organization’s  risk  thresholds. 

Other  project  documents  updated  could  include: 

• Assumptions  log  updates.  As  new  information  becomes  available  through  the  application  of  risk 
responses,  assumptions  could  change.  The  assumptions  log  needs  to  be  revisited  to  accommodate  this 
new  information. 

• Technical  documentation  updates.  As  new  information  becomes  available  through  the  application 
of  risk  responses,  technical  approaches  and  physical  deliverables  may  change.  Any  supporting 
documentation  needs  to  be  revisited  to  accommodate  this  new  information. 

• Change  requests.  Planning  for  possible  risk  responses  can  often  result  in  recommendations  for  changes 
to  the  resources,  activities,  cost  estimates,  and  other  items  identified  during  other  planning  processes. 
When  such  recommendations  are  identified,  change  requests  are  generated  and  processed  through  the 
Perform  Integrated  Change  Control  process. 
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11.6  Control  Risks 

Control  Risks  is  the  process  of  implementing  risk  response  plans,  tracking  identified  risks,  monitoring  residual 
risks,  identifying  new  risks,  and  evaluating  risk  process  effectiveness  throughout  the  project.  The  key  benefit  of 
this  process  is  that  it  improves  efficiency  of  the  risk  approach  throughout  the  project  life  cycle  to  continuously 
optimize  risk  responses.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  1 1 -20. 
Figure  1 1 -21  depicts  the  data  flow  diagram  of  the  process. 


Inputs 


.1  Project  management  plan 
.2  Risk  register 
.3  Work  performance  data 
.4  Work  performance 
reports 

V / 


Tools  & Techniques 


.1  Risk  reassessment 
.2  Risk  audits 
.3  Variance  and  trend 
analysis 

.4  Technical  performance 
measurement 
.5  Reserve  analysis 
.6  Meetings 


Outputs 


.1  Work  performance 
information 
.2  Change  requests 
.3  Project  management  plan 
updates 

.4  Project  documents 
updates 

.5  Organizational  process 
assets  updates 

v . y 


Figure  11-20.  Control  Risks:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  11-21.  Control  Risks  Data  Flow  Diagram 
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Planned  risk  responses  that  are  included  in  the  risk  register  are  executed  during  the  life  cycle  of  the  project,  but 
the  project  work  should  be  continuously  monitored  for  new,  changing,  and  outdated  risks. 

The  Control  Risks  process  applies  techniques,  such  as  variance  and  trend  analysis,  which  require  the  use  of 
performance  information  generated  during  project  execution.  Other  purposes  of  the  Control  Risks  process  are  to 
determine  if: 

• Project  assumptions  are  still  valid, 

• Analysis  shows  an  assessed  risk  has  changed  or  can  be  retired, 

• Risk  management  policies  and  procedures  are  being  followed,  and 

• Contingency  reserves  for  cost  or  schedule  should  be  modified  in  alignment  with  the  current  risk 
assessment. 

Control  Risks  can  involve  choosing  alternative  strategies,  executing  a contingency  or  fallback  plan,  taking 
corrective  action,  and  modifying  the  project  management  plan.  The  risk  response  owner  reports  periodically  to  the 
project  manager  on  the  effectiveness  of  the  plan,  any  unanticipated  effects,  and  any  correction  needed  to  handle 
the  risk  appropriately.  Control  Risks  also  includes  updating  the  organizational  process  assets,  including  project 
lessons  learned  databases  and  risk  management  templates,  for  the  benefit  of  future  projects. 

11.6.1  Control  Risks:  Inputs 

11.6.1.1  Project  Management  Plan 

Described  in  Section  4.2. 3.1 . The  project  management  plan,  which  includes  the  risk  management  plan,  provides 
guidance  for  risk  monitoring  and  controlling. 

11.6.1.2  Risk  Register 

The  risk  register  has  key  inputs  that  include  identified  risks  and  risk  owners,  agreed-upon  risk  responses, 
control  actions  for  assessing  the  effectiveness  of  response  plans,  risk  responses,  specific  implementation  actions, 
symptoms  and  warning  signs  of  risk,  residual  and  secondary  risks,  a watch  list  of  low-priority  risks,  and  the  time 
and  cost  contingency  reserves.  The  watch  list  is  within  the  risk  register  and  provides  a list  of  low-priority  risks. 
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1 1 .6.1 .3  Work  Performance  Data 

Described  in  Section  4.3. 3.2.  Work  performance  data  related  to  various  performance  results  possibly  impacted 
by  risks  includes,  but  is  not  limited  to: 

• Deliverable  status, 

• Schedule  progress,  and 

• Costs  incurred. 

1 1 .6.1 .4  Work  Performance  Reports 

Described  in  Section  4.4. 3.2.  Work  performance  reports  take  information  from  performance  measurements 
and  analyze  it  to  provide  project  work  performance  information  including  variance  analysis,  earned  value  data,  and 
forecasting  data.  These  data  points  could  be  impactful  in  controlling  performance  related  risks. 


11.6.2  Control  Risks:  Tools  and  Techniques 

11.6.2.1  Risk  Reassessment 


Control  Risks  often  results  in  identification  of  new  risks,  reassessment  of  current  risks,  and  the  closing  of  risks 
that  are  outdated.  Project  risk  reassessments  should  be  regularly  scheduled.  The  amount  and  detail  of  repetition 
that  are  appropriate  depends  on  how  the  project  progresses  relative  to  its  objectives. 


11.6.2.2  Risk  Audits 

Risk  audits  examine  and  document  the  effectiveness  of  risk  responses  in  dealing  with  identified  risks  and  their 
root  causes,  as  well  as  the  effectiveness  of  the  risk  management  process.  The  project  manager  is  responsible  for 
ensuring  that  risk  audits  are  performed  at  an  appropriate  frequency,  as  defined  in  the  project’s  risk  management 
plan.  Risk  audits  may  be  included  during  routine  project  review  meetings,  or  the  team  may  choose  to  hold  separate 
risk  audit  meetings.  The  format  for  the  audit  and  its  objectives  should  be  clearly  defined  before  the  audit  is  conducted. 
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11.6.2.3  Variance  and  Trend  Analysis 

Many  control  processes  employ  variance  analysis  to  compare  the  planned  results  to  the  actual  results.  For  the 
purposes  of  controlling  risks,  trends  in  the  project’s  execution  should  be  reviewed  using  performance  information. 
Earned  value  analysis  and  other  methods  of  project  variance  and  trend  analysis  may  be  used  for  monitoring  overall 
project  performance.  Outcomes  from  these  analyses  may  forecast  potential  deviation  of  the  project  at  completion 
from  cost  and  schedule  targets.  Deviation  from  the  baseline  plan  may  indicate  the  potential  impact  of  threats  or 
opportunities. 

11.6.2.4  Technical  Performance  Measurement 

Technical  performance  measurement  compares  technical  accomplishments  during  project  execution  to  the 
schedule  of  technical  achievement.  It  requires  the  definition  of  objective,  quantifiable  measures  of  technical 
performance,  which  can  be  used  to  compare  actual  results  against  targets.  Such  technical  performance  measures 
may  include  weight,  transaction  times,  number  of  delivered  defects,  storage  capacity,  etc.  Deviation,  such  as 
demonstrating  more  or  less  functionality  than  planned  at  a milestone,  can  help  to  forecast  the  degree  of  success 
in  achieving  the  project’s  scope. 

11.6.2.5  Reserve  Analysis 

Throughout  execution  of  the  project,  some  risks  may  occur  with  positive  or  negative  impacts  on  budget  or 
schedule  contingency  reserves.  Reserve  analysis  compares  the  amount  of  the  contingency  reserves  remaining  to 
the  amount  of  risk  remaining  at  anytime  in  the  project  in  order  to  determine  if  the  remaining  reserve  is  adequate. 

11.6.2.6  Meetings 

Project  risk  management  should  be  an  agenda  item  at  periodic  status  meetings.  The  amount  of  time  required 
for  that  item  will  vary,  depending  upon  the  risks  that  have  been  identified,  their  priority,  and  difficulty  of  response. 
The  more  often  risk  management  is  practiced,  the  easier  it  becomes.  Frequent  discussions  about  risk  make  it  more 
likely  that  people  will  identify  risks  and  opportunities. 
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1 1 .6.3  Control  Risks:  Outputs 


11.6.3.1  Work  Performance  Information 

Work  performance  information,  as  a Control  Risks  output,  provides  a mechanism  to  communicate  and  support 
project  decision  making. 


11.6.3.2  Change  Requests 

Implementing  contingency  plans  or  workarounds  sometimes  results  in  a change  request.  Change  requests  are 
prepared  and  submitted  to  the  Perform  Integrated  Change  Control  process  (Section  4.5).  Change  requests  can 
include  recommended  corrective  and  preventive  actions  as  well. 

• Recommended  corrective  actions.  These  are  activities  that  realign  the  performance  of  the  project 
work  with  the  project  management  plan.  They  include  contingency  plans  and  workarounds.  The  latter 
are  responses  that  were  not  initially  planned,  but  are  required  to  deal  with  emerging  risks  that  were 
previously  unidentified  or  accepted  passively. 

• Recommended  preventive  actions.  These  are  activities  that  ensure  that  future  performance  of  the 
project  work  is  aligned  with  the  project  management  plan. 


11.6.3.3  Project  Management  Plan  Updates 

If  the  approved  change  requests  have  an  effect  on  the  risk  management  processes,  the  corresponding  component 
documents  of  the  project  management  plan  are  revised  and  reissued  to  reflect  the  approved  changes.  The  elements 
of  the  project  management  plan  that  may  be  updated  are  the  same  as  those  in  the  Plan  Risk  Responses  process. 
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11.6.3.4  Project  Documents  Updates 

Project  documents  that  may  be  updated  as  a result  of  the  Control  Risk  process  include,  but  are  not  limited  to  the 
risk  register.  Risk  register  updates  may  include: 

• Outcomes  of  risk  reassessments,  risk  audits,  and  periodic  risk  reviews.  These  outcomes  may 
include  identification  of  new  risks,  updates  to  probability,  impact,  priority,  response  plans,  ownership,  and 
other  elements  of  the  risk  register.  Outcomes  can  also  include  closing  risks  that  are  no  longer  applicable 
and  releasing  their  associated  reserves. 

• Actual  outcomes  of  the  project’s  risks  and  of  the  risk  responses.  This  information  can  help  project 
managers  to  plan  for  risk  throughout  their  organizations,  as  well  as  on  future  projects. 

11.6.3.5  Organizational  Process  Assets  Updates 

The  risk  management  processes  produce  information  that  may  be  used  for  future  projects,  and  should  be 
captured  in  the  organizational  process  assets.  The  organizational  process  assets  that  may  be  updated  include,  but 
are  not  limited  to: 

• Templates  for  the  risk  management  plan,  including  the  probability  and  impact  matrix  and  risk  register, 

• Risk  breakdown  structure,  and 

• Lessons  learned  from  the  project  risk  management  activities. 

These  documents  should  be  updated  as  needed  and  at  project  closure.  Final  versions  of  the  risk  register  and  the 
risk  management  plan  templates,  checklists,  and  risk  breakdown  structure  are  included. 
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12 

PROJECT  PROCUREMENT  MANAGEMENT 


Project  Procurement  Management  includes  the  processes  necessary  to  purchase  or  acquire  products,  services, 
or  results  needed  from  outside  the  project  team.  The  organization  can  be  either  the  buyer  or  seller  of  the  products, 
services,  or  results  of  a project. 

Project  Procurement  Management  includes  the  contract  management  and  change  control  processes  required  to 
develop  and  administer  contracts  or  purchase  orders  issued  by  authorized  project  team  members. 

Project  Procurement  Management  also  includes  controlling  any  contract  issued  by  an  outside  organization  (the 
buyer)  that  is  acquiring  deliverables  from  the  project  from  the  performing  organization  (the  seller),  and  administering 
contractual  obligations  placed  on  the  project  team  by  the  contract. 

Figure  12-1  provides  an  overview  of  the  Project  Procurement  Management  processes  which  include  the 
following:  12 

12.1  Plan  Procurement  Management — The  process  of  documenting  project  procurement  decisions, 
specifying  the  approach,  and  identifying  potential  sellers. 

12.2  Conduct  Procurements — The  process  of  obtaining  seller  responses,  selecting  a seller,  and  awarding 
a contract. 

12.3  Control  Procurements — The  process  of  managing  procurement  relationships,  monitoring  contract 
performance,  and  making  changes  and  corrections  as  appropriate. 

12.4  Close  Procurements — The  process  of  completing  each  project  procurement. 

These  processes  interact  with  each  other  and  with  processes  in  other  Knowledge  Areas  as  described  in  detail 
in  Section  3 and  Annex  A1. 
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Figure  12-1.  Project  Procurement  Management  Overview 
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The  Project  Procurement  Management  processes  involve  agreements,  including  contracts,  which  are  legal 
documents  between  a buyer  and  a seller.  A contract  represents  a mutually  binding  agreement  that  obligates  the 
seller  to  provide  something  of  value  (e.g.,  specified  products,  services,  or  results)  and  obligates  the  buyer  to  provide 
monetary  or  other  valuable  compensation.  An  agreement  can  be  simple  or  complex,  and  may  reflect  the  simplicity 
or  complexity  of  the  deliverables  or  required  effort. 

A procurement  contract  includes  terms  and  conditions,  and  may  incorporate  other  items  that  the  buyer 
specifies  as  to  what  the  seller  is  to  perform  or  provide.  It  is  the  project  management  team’s  responsibility  to  make 
certain  that  all  procurements  meet  the  specific  needs  of  the  project  while  adhering  to  organizational  procurement 
policies.  Depending  upon  the  application  area,  a contract  can  also  be  called  an  agreement,  an  understanding, 
a subcontract,  or  a purchase  order.  Most  organizations  document  policies  and  procedures  specifically  defining 
the  procurement  rules  and  specifying  who  has  authority  to  sign  and  administer  such  agreements  on  behalf  of 
the  organization. 

Although  all  project  documents  may  be  subject  to  some  form  of  review  and  approval,  the  legally  binding  nature 
of  a contract  or  agreement  usually  means  it  will  be  subjected  to  a more  extensive  approval  process.  In  all  cases,  the 
primary  focus  of  the  review  and  approval  process  is  to  ensure  that  the  contract  language  describes  the  products, 
services,  or  results  that  will  satisfy  the  identified  project  need. 

The  project  management  team  may  seek  support  in  early  phases  from  specialists  in  contracting,  purchasing, 
law,  and  technical  disciplines.  Such  involvement  can  be  mandated  by  an  organization’s  policies. 

The  various  activities  involved  in  the  Project  Procurement  Management  processes  form  the  life  cycle  of  an 
agreement.  By  actively  managing  the  agreement  life  cycle  and  carefully  wording  the  terms  and  conditions  of  a 
procurement,  some  identifiable  project  risks  may  be  shared  or  transferred  to  a seller.  Entering  into  an  agreement 
for  products  or  services  is  one  method  of  allocating  the  responsibility  for  managing  or  sharing  potential  risks. 

A complex  project  may  involve  managing  multiple  contracts  or  subcontracts  simultaneously  or  in  sequence. 
In  such  cases,  each  contract  life  cycle  may  end  during  any  phase  of  the  project  life  cycle.  Project  Procurement 
Management  is  discussed  within  the  perspective  of  the  buyer-seller  relationship.  The  buyer-seller  relationship 
may  exist  at  many  levels  on  any  one  project,  and  between  organizations  internal  to  and  external  to  the  acquiring 
organization. 

Depending  on  the  application  area,  the  seller  may  be  identified  as  a contractor,  subcontractor,  vendor,  service 
provider,  or  supplier.  Depending  on  the  buyer’s  position  in  the  project  acquisition  cycle,  the  buyer  may  be  called  a 
client,  customer,  prime  contractor,  contractor,  acquiring  organization,  service  requestor,  or  purchaser.  The  seller  can 
be  viewed  during  the  contract  life  cycle  first  as  a bidder,  then  as  the  selected  source,  and  then  as  the  contracted 
supplier  or  vendor. 
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The  seller  will  typically  manage  the  work  as  a project  if  the  acquisition  is  not  just  for  shelf  material,  goods,  or 
common  products.  In  such  cases: 

• The  buyer  becomes  the  customer,  and  is  thus  a key  project  stakeholder  for  the  seller. 

• The  seller’s  project  management  team  is  concerned  with  all  the  processes  of  project  management,  not 
only  with  those  of  this  Knowledge  Area. 

• Terms  and  conditions  of  the  contract  become  key  inputs  to  many  of  the  seller’s  management  processes. 
The  contract  can  actually  contain  the  inputs  (e.g.,  major  deliverables,  key  milestones,  cost  objectives), 
or  it  can  limit  the  project  team’s  options  (e.g.,  buyer  approval  of  staffing  decisions  is  often  required  on 
design  projects). 

In  this  section,  it  is  assumed  that  the  buyer  of  an  item  for  the  project  is  assigned  to  the  project  team  and  that  the 
seller  is  organizationally  external  to  the  project  team.  It  is  also  assumed  that  a formal  contractual  relationship  will 
be  developed  and  exists  between  the  buyer  and  the  seller.  However,  most  of  the  discussion  in  this  section  is  equally 
applicable  to  non-contractual  work  entered  into  with  other  units  of  the  project  team’s  organization. 


12.1  Plan  Procurement  Management 

Plan  Procurement  Management  is  the  process  of  documenting  project  procurement  decisions,  specifying  the 
approach,  and  identifying  potential  sellers.  The  key  benefit  of  this  process  is  that  it  determines  whether  to  acquire 
outside  support,  and  if  so,  what  to  acquire,  how  to  acquire  it,  how  much  is  needed,  and  when  to  acquire  it.  The 
inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  1 2-2.  Figure  1 2-3  depicts  the  data 
flow  diagram  of  the  process. 
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Figure  12-2.  Plan  Procurements:  Inputs,  Tools  & Techniques,  and  Outputs 
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Plan  Procurement  Management  identifies  those  project  needs  that  can  best  be  met  or  should  be  met  by 
acquiring  products,  services,  or  results  outside  of  the  project  organization,  versus  those  project  needs  which  can 
be  accomplished  by  the  project  team.  When  the  project  obtains  products,  services,  and  results  required  for  project 
performance  from  outside  of  the  performing  organization,  the  processes  from  Plan  Procurement  Management 
through  Close  Procurements  are  performed  for  each  item  to  be  acquired. 
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The  Plan  Procurement  Management  process  also  includes  evaluating  potential  sellers,  particularly  if  the  buyer 
wishes  to  exercise  some  degree  of  influence  or  control  over  acquisition  decisions.  Thought  should  also  be  given  to 
who  is  responsible  for  obtaining  or  holding  any  relevant  permits  and  professional  licenses  that  may  be  required  by 
legislation,  regulation,  or  organizational  policy  in  executing  the  project. 

The  requirements  of  the  project  schedule  can  significantly  influence  the  strategy  during  the  Plan  Procurement 
Management  process.  Decisions  made  in  developing  the  procurement  management  plan  can  also  influence  the 
project  schedule  and  are  integrated  with  Develop  Schedule,  Estimate  Activity  Resources,  and  make-or-buy  analysis. 

The  Plan  Procurement  Management  process  includes  evaluating  the  risks  involved  with  each  make-or-buy 
analysis.  It  also  includes  reviewing  the  type  of  contract  planned  to  be  used  with  respect  to  avoiding  or  mitigating 
risks,  sometimes  transferring  risks  to  the  seller. 

12.1.1  Plan  Procurement  Management:  Inputs 

12.1.1.1  Project  Management  Plan 

Described  in  Section  4. 2.3.1 . The  project  management  plan  describes  the  need,  justification,  requirements,  and 
current  boundaries  for  the  project.  It  includes,  but  is  not  limited  to,  the  scope  baseline  contents: 

• Project  scope  statement.  The  project  scope  statement  contains  the  product  scope  description,  service 
description  and  result  description,  the  list  of  deliverables,  and  acceptance  criteria,  as  well  as  important 
information  regarding  technical  issues  or  concerns  that  could  impact  cost  estimating.  Identified 
constraints  may  include  required  delivery  dates,  available  skilled  resources,  and  organizational  policies. 

• WBS.  The  work  breakdown  structure  (WBS)  contains  the  components  of  work  that  may  be  resourced 
externally. 

• WBS  dictionary.  The  WBS  dictionary  and  related  detailed  statements  of  work  provide  an  identification 
of  the  deliverables  and  a description  of  the  work  in  each  WBS  component  required  to  produce  each 
deliverable. 
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12.1.1.2  Requirements  Documentation 

Described  in  Section  5.2. 3.1 . Requirements  documentation  may  include: 

• Important  information  about  project  requirements  that  is  considered  during  planning  for  procurements, 
and 

• Requirements  with  contractual  and  legal  implications  that  may  include  health,  safety,  security, 
performance,  environmental,  insurance,  intellectual  property  rights,  equal  employment  opportunity, 
licenses,  and  permits — all  of  which  are  considered  when  planning  for  procurements. 

12.1.1.3  Risk  Register 

Described  in  Section  1 1 .2.3.1 . The  risk  register  provides  the  list  of  risks,  along  with  the  results  of  risk  analysis 
and  risk  response  planning.  Updates  to  the  risk  register  are  included  with  project  document  updates  described  in 
Section  1 1 .5.3.2,  from  the  Plan  Risk  Responses  process. 


12.1 .1 .4  Activity  Resource  Requirements 

Described  in  Section  6. 4.3.1.  Activity  resource  requirements  contain  information  on  specific  needs  such  as 
people,  equipment,  or  location. 


1 2.1 .1 .5  Project  Schedule 

Described  in  Section  6.6. 3.2.  Project  schedule  contains  information  on  required  timelines  or  mandated 
deliverable  dates. 


12.1 .1 .6  Activity  Cost  Estimates 

Described  in  Section  7. 2.3.1.  Cost  estimates  developed  by  the  procuring  activity  are  used  to  evaluate  the 
reasonableness  of  the  bids  or  proposals  received  from  potential  sellers. 

12.1.1.7  Stakeholder  Register 

Described  in  Section  13.1.3.1.  The  stakeholder  register  provides  details  on  the  project  participants  and  their 
interests  in  the  project. 
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12.1.1.8  Enterprise  Environmental  Factors 

Described  in  Section  2.1 .5.  The  enterprise  environmental  factors  that  can  influence  the  Plan  Procurement 
Management  process  include,  but  are  not  limited  to: 

• Marketplace  conditions; 

• Products,  services,  and  results  that  are  available  in  the  marketplace; 

• Suppliers,  including  past  performance  or  reputation; 

• Typical  terms  and  conditions  for  products,  services,  and  results  or  for  the  specific  industry;  and 

• Unique  local  requirements. 

12.1.1.9  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  The  various  types  of  contractual  agreements  used  by  the  organization  also  influence 
decisions  for  the  Plan  Procurement  Management  process.  The  organizational  process  assets  that  influence  the  Plan 
Procurement  Management  process  include,  but  are  not  limited  to: 

• Formal  procurement  policies,  procedures,  and  guidelines.  Most  organizations  have  formal  procurement 
policies  and  buying  organizations.  When  such  procurement  support  is  not  available,  the  project  team 
should  supply  both  the  resources  and  the  expertise  to  perform  such  procurement  activities. 

• Management  systems  that  are  considered  in  developing  the  procurement  management  plan  and  selecting 
the  contractual  relationships  to  be  used. 

• An  established  multi-tier  supplier  system  of  prequalified  sellers  based  on  prior  experience. 

All  legal  contractual  relationships  generally  fall  into  one  of  two  broad  families:  either  fixed-price  or  cost 
reimbursable.  Also,  there  is  a third  hybrid  type  commonly  in  use  called  the  time  and  materials  contract.  The  more 
popular  contract  types  in  use  are  discussed  below  as  discrete  types,  but  in  practice  it  is  not  unusual  to  combine 
one  or  more  types  into  a single  procurement. 

• Fixed-price  contracts.  This  category  of  contracts  involves  setting  a fixed  total  price  for  a defined  product, 
service,  or  result  to  be  provided.  Fixed-price  contracts  may  also  incorporate  financial  incentives  for 
achieving  or  exceeding  selected  project  objectives,  such  as  schedule  delivery  dates,  cost  and  technical 
performance,  or  anything  that  can  be  quantified  and  subsequently  measured.  Sellers  under  fixed-price 
contracts  are  legally  obligated  to  complete  such  contracts,  with  possible  financial  damages  if  they  do 
not.  Under  the  fixed-price  arrangement,  buyers  need  to  precisely  specify  the  product  or  services  being 
procured.  Changes  in  scope  may  be  accommodated,  but  generally  with  an  increase  in  contract  price. 
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o Firm  Fixed  Price  Contracts  (FFP).  The  most  commonly  used  contract  type  is  the  FFP.  It  is 
favored  by  most  buying  organizations  because  the  price  for  goods  is  set  at  the  outset  and 
not  subject  to  change  unless  the  scope  of  work  changes.  Any  cost  increase  due  to  adverse 
performance  is  the  responsibility  of  the  seller,  who  is  obligated  to  complete  the  effort.  Under 
the  FFP  contract,  the  buyer  should  precisely  specify  the  product  or  services  to  be  procured, 
and  any  changes  to  the  procurement  specification  can  increase  the  costs  to  the  buyer. 

o Fixed  Price  Incentive  Fee  Contracts  (FPIF).  This  fixed-price  arrangement  gives  the  buyer  and 
seller  some  flexibility  in  that  it  allows  for  deviation  from  performance,  with  financial  incentives 
tied  to  achieving  agreed  upon  metrics.  Typically  such  financial  incentives  are  related  to  cost, 
schedule,  or  technical  performance  of  the  seller.  Performance  targets  are  established  at  the 
outset,  and  the  final  contract  price  is  determined  after  completion  of  all  work  based  on  the 
seller’s  performance.  Under  FPIF  contracts,  a price  ceiling  is  set,  and  all  costs  above  the  price 
ceiling  are  the  responsibility  of  the  seller,  who  is  obligated  to  complete  the  work. 

o Fixed  Price  with  Economic  Price  Adjustment  Contracts  (FP-EPA).  This  contract  type  is  used 
whenever  the  seller’s  performance  period  spans  a considerable  period  of  years,  as  is  desired 
with  many  long-term  relationships.  It  is  a fixed-price  contract,  but  with  a special  provision 
allowing  for  pre  defined  final  adjustments  to  the  contract  price  due  to  changed  conditions,  such 
as  inflation  changes,  or  cost  increases  (or  decreases)  for  specific  commodities.  The  EPA  clause 
needs  to  relate  to  some  reliable  financial  index,  which  is  used  to  precisely  adjust  the  final  price. 
The  FP-EPA  contract  is  intended  to  protect  both  buyer  and  seller  from  external  conditions  beyond 
their  control. 

• Cost-reimbursable  contracts.  This  category  of  contract  involves  payments  (cost  reimbursements)  to 
the  seller  for  all  legitimate  actual  costs  incurred  for  completed  work,  plus  a fee  representing  seller  profit. 
Cost-reimbursable  contracts  may  also  include  financial  incentive  clauses  whenever  the  seller  exceeds, 
or  falls  below,  defined  objectives  such  as  costs,  schedule,  or  technical  performance  targets.  Three  of 
the  more  common  types  of  cost-reimbursable  contracts  in  use  are  Cost  Plus  Fixed  Fee  (CPFF),  Cost  Plus 
Incentive  Fee  (CPIF),  and  Cost  Plus  Award  Fee  (CPAF). 

A cost-reimbursable  contract  provides  the  project  flexibility  to  redirect  a seller  whenever  the  scope  of 
work  cannot  be  precisely  defined  at  the  start  and  needs  to  be  altered,  or  when  high  risks  may  exist  in 
the  effort. 
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o Cost  Plus  Fixed  Fee  Contracts  (CPFF).  The  seller  is  reimbursed  for  all  allowable  costs  for 
performing  the  contract  work,  and  receives  a fixed-fee  payment  calculated  as  a percentage  of 
the  initial  estimated  project  costs.  A fee  is  paid  only  for  completed  work  and  does  not  change 
due  to  seller  performance.  Fee  amounts  do  not  change  unless  the  project  scope  changes. 

o Cost  Plus  Incentive  Fee  Contracts  (CPIF).  The  seller  is  reimbursed  for  all  allowable  costs  for 
performing  the  contract  work  and  receives  a predetermined  incentive  fee  based  upon  achieving 
certain  performance  objectives  as  set  forth  in  the  contract.  In  CPIF  contracts,  if  the  final  costs 
are  less  or  greater  than  the  original  estimated  costs,  then  both  the  buyer  and  seller  share  costs 
from  the  departures  based  upon  a prenegotiated  cost-sharing  formula,  for  example,  an  80/20 
split  over/under  target  costs  based  on  the  actual  performance  of  the  seller. 

o Cost  Plus  Award  Fee  Contracts  (CPAF).  The  seller  is  reimbursed  for  all  legitimate  costs,  but 
the  majority  of  the  fee  is  earned  only  based  on  the  satisfaction  of  certain  broad  subjective 
performance  criteria  defined  and  incorporated  into  the  contract.  The  determination  of  fee  is 
based  solely  on  the  subjective  determination  of  seller  performance  by  the  buyer,  and  is  generally 
not  subject  to  appeals. 

• Time  and  Material  Contracts  (T&M).  Time  and  material  contracts  are  a hybrid  type  of  contractual 
arrangement  that  contain  aspects  of  both  cost-reimbursable  and  fixed-price  contracts.  They  are  often 
used  for  staff  augmentation,  acquisition  of  experts,  and  any  outside  support  when  a precise  statement 
of  work  cannot  be  quickly  prescribed.  These  types  of  contracts  resemble  cost-reimbursable  contracts  in 
that  they  can  be  left  open  ended  and  may  be  subject  to  a cost  increase  for  the  buyer.  The  full  value  of 
the  agreement  and  the  exact  quantity  of  items  to  be  delivered  may  not  be  defined  by  the  buyer  at  the 
time  of  the  contract  award.  Thus,  T&M  contracts  can  increase  in  contract  value  as  if  they  were  cost- 
reimbursable  contracts.  Many  organizations  require  not-to-exceed  values  and  time  limits  placed  in  all 
T&M  contracts  to  prevent  unlimited  cost  growth.  Conversely,  T&M  contracts  can  also  resemble  fixed 
unit  price  arrangements  when  certain  parameters  are  specified  in  the  contract.  Unit  labor  or  material 
rates  can  be  preset  by  the  buyer  and  seller,  including  seller  profit,  when  both  parties  agree  on  the  values 
for  specific  resource  categories,  such  as  senior  engineers  at  specified  rates  per  hour,  or  categories  of 
materials  at  specified  rates  per  unit. 
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12.1.2  Plan  Procurement  Management:  Tools  and  Techniques 

12.1.2.1  Make-or-Buy  Analysis 

A make-or-buy  analysis  is  a general  management  technique  used  to  determine  whether  particular  work  can 
best  be  accomplished  by  the  project  team  or  should  be  purchased  from  outside  sources.  Sometimes  a capability 
may  exist  within  the  project  organization,  but  may  be  committed  to  working  on  other  projects,  in  which  case,  the 
project  may  need  to  source  such  effort  from  outside  the  organization  in  order  to  meet  its  schedule  commitments. 

Budget  constraints  may  influence  make-or-buy  decisions.  If  a buy  decision  is  to  be  made,  then  a further  decision 
of  whether  to  purchase  or  lease  is  also  made.  A make-or-buy  analysis  should  consider  all  related  costs — both 
direct  costs  as  well  as  indirect  support  costs.  For  example,  the  buy-side  of  the  analysis  includes  both  the  actual 
out-of-pocket  costs  to  purchase  the  product,  as  well  as  the  indirect  costs  of  supporting  the  purchasing  process  and 
purchased  item. 

Available  contract  types  are  also  considered  during  the  buy  analysis.  The  risk  sharing  between  the  buyer 
and  seller  determines  the  suitable  contract  types,  while  the  specific  contract  terms  and  conditions  formalize  the 
degree  of  risk  being  assumed  by  the  buyer  and  seller.  Some  jurisdictions  have  other  types  of  contracts  defined,  for 
example,  contract  types  based  on  the  obligations  of  the  seller — not  the  customer — and  the  contract  parties  have  12 
the  obligation  to  identify  the  appropriate  type  of  contract  as  soon  as  the  applicable  law  has  been  agreed  upon. 

12.1.2.2  Expert  Judgment 

Expert  judgment  is  often  used  to  assess  the  inputs  to  and  outputs  from  this  process.  Expert  purchasing  judgment 
can  also  be  used  to  develop  or  modify  the  criteria  that  will  be  used  to  evaluate  seller  proposals.  Expert  legal 
judgment  may  involve  the  services  of  legal  staff  to  assist  with  unique  procurement  issues,  terms,  and  conditions. 

Such  judgment,  including  business  and  technical  expertise,  can  be  applied  to  both  the  technical  details  of  the 
acquired  products,  services,  or  results  and  to  various  aspects  of  the  procurement  management  processes. 

12.1.2.3  Market  Research 

Market  research  includes  examination  of  industry  and  specific  vendor  capabilities.  Procurement  teams  may 
leverage  information  gained  at  conferences,  online  reviews  and  a variety  of  sources  to  identify  market  capabilities. 

The  team  may  also  refine  particular  procurement  objectives  to  leverage  maturing  technologies  while  balancing 
risks  associated  with  the  breadth  of  vendors  who  can  provide  the  materials  or  services  desired. 
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12.1.2.4  Meetings 

Research  alone  may  not  provide  specific  information  to  formulate  a procurement  strategy  without  additional 
information  interchange  meetings  with  potential  bidders.  By  collaborating  with  potential  bidders,  the  organization 
purchasing  the  material  or  service  may  benefit  while  the  supplier  can  influence  a mutually  beneficial  approach  or 
product. 

12.1.3  Plan  Procurement  Management:  Outputs 
12.1.3.1  Procurement  Management  Plan 

The  procurement  management  plan  is  a component  of  the  project  management  plan  that  describes  how  a project 
team  will  acquire  goods  and  services  from  outside  the  performing  organization.  It  describes  how  the  procurement 
processes  will  be  managed  from  developing  procurement  documents  through  contract  closure.  The  procurement 
management  plan  can  include  guidance  for: 

• Types  of  contracts  to  be  used; 

• Risk  management  issues; 

• Whether  independent  estimates  will  be  used  and  whether  they  are  needed  as  evaluation  criteria; 

• Those  actions  the  project  management  team  can  take  unilaterally,  if  the  performing  organization  has  a 
prescribed  procurement,  contracting,  or  purchasing  department; 

• Standardized  procurement  documents,  if  needed; 

• Managing  multiple  suppliers; 

• Coordinating  procurement  with  other  project  aspects,  such  as  scheduling  and  performance  reporting; 

• Any  constraints  and  assumptions  that  could  affect  planned  procurements; 

• Handling  the  long  lead  times  to  purchase  certain  items  from  sellers  and  coordinating  the  extra  time 
needed  to  procure  these  items  with  the  development  of  the  project  schedule; 

• Handling  the  make-or-buy  decisions  and  linking  them  into  the  Estimate  Activity  Resources  and  Develop 
Schedule  processes; 
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• Setting  the  scheduled  dates  in  each  contract  for  the  contract  deliverables  and  coordinating  with  the 
schedule  development  and  control  processes; 

• Identifying  requirements  for  performance  bonds  or  insurance  contracts  to  mitigate  some  forms  of  project 
risk; 

• Establishing  the  direction  to  be  provided  to  the  sellers  on  developing  and  maintaining  a work  breakdown 
structure  (WBS); 

• Establishing  the  form  and  format  to  be  used  for  the  procurement/contract  statements  of  work; 

• Identifying  prequalified  sellers,  if  any,  to  be  used;  and 

• Procurement  metrics  to  be  used  to  manage  contracts  and  evaluate  sellers. 

A procurement  management  plan  can  be  formal  or  informal,  can  be  highly  detailed  or  broadly  framed,  and  is 
based  upon  the  needs  of  each  project. 


12.1 .3.2  Procurement  Statement  of  Work 


The  statement  of  work  (SOW)  for  each  procurement  is  developed  from  the  project  scope  baseline  and  defines 
only  that  portion  of  the  project  scope  that  is  to  be  included  within  the  related  contract.  The  procurement  SOW 
describes  the  procurement  item  in  sufficient  detail  to  allow  prospective  sellers  to  determine  if  they  are  capable  of 
providing  the  products,  services,  or  results.  Sufficient  detail  can  vary  based  on  the  nature  of  the  item,  the  needs  of 
the  buyer,  or  the  expected  contract  form.  Information  included  in  a SOW  can  include  specifications,  quantity  desired, 
quality  levels,  performance  data,  period  of  performance,  work  location,  and  other  requirements. 

The  procurement  SOW  is  written  to  be  clear,  complete,  and  concise.  It  includes  a description  of  any  collateral 
services  required,  such  as  performance  reporting  or  post-project  operational  support  for  the  procured  item.  In  some 
application  areas,  there  are  specific  content  and  format  requirements  for  a procurement  SOW.  Each  individual 
procurement  item  requires  a SOW;  however,  multiple  products  or  services  can  be  grouped  as  one  procurement 
item  within  a single  SOW. 

The  procurement  SOW  can  be  revised  and  refined  as  required  as  it  moves  through  the  procurement  process 
until  incorporated  into  a signed  agreement. 
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12.1.3.3  Procurement  Documents 

Procurement  documents  are  used  to  solicit  proposals  from  prospective  sellers.  Terms  such  as  bid,  tender,  or 
quotation  are  generally  used  when  the  seller  selection  decision  will  be  based  on  price  (as  when  buying  commercial 
or  standard  items),  while  a term  such  as  proposal  is  generally  used  when  other  considerations,  such  as  technical 
capability  or  technical  approach  are  paramount.  Common  terms  are  in  use  for  different  types  of  procurement 
documents  and  may  include  request  for  information  (RFI),  invitation  for  bid  (IFB),  request  for  proposal  (RFP),  request 
for  quotation  (RFQ),  tender  notice,  invitation  for  negotiation,  and  invitation  for  seller’s  initial  response.  Specific 
procurement  terminology  used  may  vary  by  industry  and  location  of  the  procurement. 

The  buyer  structures  procurement  documents  to  facilitate  an  accurate  and  complete  response  from  each 
prospective  seller  and  to  facilitate  easy  evaluation  of  the  responses.  These  documents  include  a description  of  the 
desired  form  of  the  response,  the  relevant  procurement  statement  of  work  (SOW)  and  any  required  contractual 
provisions.  With  government  contracting,  some  or  all  of  the  content  and  structure  of  procurement  documents  may 
be  defined  by  regulation. 

The  complexity  and  level  of  detail  of  the  procurement  documents  should  be  consistent  with  the  value  of,  and 
risks  associated  with,  the  planned  procurement.  Procurement  documents  are  required  to  be  sufficient  to  ensure 
consistent,  appropriate  responses,  but  flexible  enough  to  allow  consideration  of  any  seller  suggestions  for  better 
ways  to  satisfy  the  same  requirements. 

Issuing  a procurement  request  to  potential  sellers  to  submit  a proposal  or  bid  is  normally  done  in  accordance 
with  the  policies  of  the  buyer’s  organization,  which  can  include  publication  of  the  request  in  public  newspapers,  in 
trade  journals,  in  public  registries,  or  on  the  internet. 

12.1.3.4  Source  Selection  Criteria 

Source  selection  criteria  are  often  included  as  a part  of  the  procurement  documents.  Such  criteria  are  developed 
and  used  to  rate  or  score  seller  proposals,  and  can  be  objective  or  subjective. 

Selection  criteria  may  be  limited  to  only  the  purchase  price  if  the  procurement  item  is  readily  available  from 
a number  of  acceptable  sellers.  Purchase  price  in  this  context  includes  both  the  cost  of  the  item  and  all  ancillary 
expenses  such  as  delivery. 

Other  selection  criteria  can  be  identified  and  documented  to  support  an  assessment  for  more  complex  products, 
services,  or  results.  Some  possible  source  selection  criteria  are: 
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• Understanding  of  need.  How  well  does  the  seller’s  proposal  address  the  procurement  statement  of 
work? 

• Overall  or  life-cycle  cost.  Will  the  selected  seller  produce  the  lowest  total  cost  of  ownership  (purchase 
cost  plus  operating  cost)? 

• Technical  capability.  Does  the  seller  have,  or  can  the  seller  be  reasonably  expected  to  acquire,  the 
technical  skills  and  knowledge  needed? 

• Risk.  How  much  risk  is  embedded  in  the  statement  of  work,  how  much  risk  will  be  assigned  to  the 
selected  seller  and  how  does  the  seller  mitigate  risk? 

• Management  approach.  Does  the  seller  have,  or  can  the  seller  be  reasonably  expected  to  develop, 
management  processes  and  procedures  to  ensure  a successful  project? 

• Technical  approach.  Do  the  seller’s  proposed  technical  methodologies,  techniques,  solutions,  and 
services  meet  the  procurement  documents  requirements  or  are  they  likely  to  provide  more  or  less  than 
the  expected  results? 

• Warranty.  What  does  the  seller  propose  to  warrant  for  the  final  product,  and  through  what  time  period? 

• Financial  capacity.  Does  the  seller  have,  or  can  the  seller  reasonably  be  expected  to  obtain,  the  necessary 
financial  resources? 

• Production  capacity  and  interest.  Does  the  seller  have  the  capacity  and  interest  to  meet  potential 
future  requirements? 

• Business  size  and  type.  Does  the  seller’s  enterprise  meet  a specific  category  of  business  such  as 
small  business  (disadvantaged,  specific  programs,  etc.)  as  defined  by  the  organization  or  established  by 
governmental  agency  and  set  forth  as  a condition  of  the  agreement  award? 

• Past  performance  of  sellers.  What  has  been  the  past  experience  with  selected  sellers? 

• References.  Can  the  seller  provide  references  from  prior  customers  verifying  the  seller’s  work  experience 
and  compliance  with  contractual  requirements? 

• Intellectual  property  rights.  Does  the  seller  assert  intellectual  property  rights  in  the  work  processes  or 
services  they  will  use  or  in  the  products  they  will  produce  for  the  project? 

• Proprietary  rights.  Does  the  seller  assert  proprietary  rights  in  the  work  processes  or  services  they  will 
use  or  in  the  products  they  will  produce  for  the  project? 
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12.1.3.5  Make-or-Buy  Decisions 

A make-or-buy  analysis  results  in  a decision  of  whether  particular  work  can  best  be  accomplished  by  the 
project  team  or  needs  to  be  purchased  from  outside  sources.  If  the  decision  is  to  make  the  item,  then  the 
procurement  plan  may  define  processes  and  agreements  internal  to  the  organization.  A buy  decision  drives  a 
similar  process  of  reaching  agreement  with  a supplier  for  the  product  or  services. 

12.1.3.6  Change  Requests 

A decision  that  involves  procuring  goods,  services,  or  resources  typically  requires  a change  request.  Other 
decisions  during  procurement  planning  can  also  create  the  need  for  additional  change  requests.  Change  requests 
are  processed  for  review  and  disposition  through  the  Perform  Integrated  Change  Control  process  (Section  4.5). 
Changes  to  the  project  management  plan,  its  subsidiary  plans,  and  other  components  may  result  in  change  requests 
that  impact  procurement  actions.  Change  requests  are  processed  for  review  and  disposition  through  the  Perform 
Integrated  Change  Control  process  (Section  4.5). 

12.1.3.7  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Requirements  documentation, 

• Requirements  traceability  matrix,  and 

• Risk  register. 
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12.2  Conduct  Procurements 

Conduct  Procurements  is  the  process  of  obtaining  seller  responses,  selecting  a seller,  and  awarding  a contract. 
The  key  benefit  of  this  process  is  that  it  provides  alignment  of  internal  and  external  stakeholder  expectations 
through  established  agreements.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in 
Figure  1 2-4.  Figure  1 2-5  depicts  the  data  flow  diagram  of  the  process. 
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Figure  12-4.  Conduct  Procurements:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  12-5.  Conduct  Procurements  Data  Flow  Diagram 

During  the  Conduct  Procurements  process,  the  team  will  receive  bids  or  proposals  and  will  apply  previously 
defined  selection  criteria  to  select  one  or  more  sellers  who  are  qualified  to  perform  the  work  and  acceptable  as  a 
seller. 
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On  major  procurement  items,  the  overall  process  of  requesting  responses  from  sellers  and  evaluating 
those  responses  can  be  repeated.  A short  list  of  qualified  sellers  can  be  established  based  on  a preliminary 
proposal.  A more  detailed  evaluation  can  then  be  conducted  based  on  a more  specific  and  comprehensive 
requirements  document  requested  from  the  sellers  on  the  short  list.  In  addition,  tools  and  techniques 
described  here  may  be  used  alone  or  in  combination  with  select  sellers.  For  example,  a weighting  system 
can  be  used  to: 

• Select  a single  seller  that  will  be  asked  to  sign  a standard  contract;  and 

• Establish  a negotiating  sequence  by  ranking  all  proposals  by  the  weighted  evaluation  scores  assigned  to 
each  proposal. 

12.2.1  Conduct  Procurements:  Inputs 

12.2.1.1  Procurement  Management  Plan 

Described  in  Section  4. 2.3.1.  The  procurement  management  plan  describes  how  the  procurement  processes 
will  be  managed  from  developing  procurement  documentation  through  contract  closure. 

12 

12.2.1.2  Procurement  Documents 

Described  in  Section  12.1.3.3.  Procurement  documents  provide  an  audit  trail  for  contracts  and  other 
agreements. 

12.2.1.3  Source  Selection  Criteria 

Described  in  Section  12.1.3.4. 

Source  selection  criteria  can  include  information  on  the  supplier’s  required  capabilities,  capacity,  delivery  dates, 
product  cost,  life-cycle  cost,  technical  expertise,  and  the  approach  to  the  contract. 

12.2.1.4  Seller  Proposals 

Seller  proposals,  prepared  in  response  to  a procurement  document  package,  form  the  basic  information  that  will 
be  used  by  an  evaluation  body  to  select  one  or  more  successful  bidders  (sellers). 
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12.2.1.5  Project  Documents 

Described  in  Section  1 1 .5.3.2.  Project  documents  that  are  often  considered  include  the  risk-related  contract 
decisions  included  within  the  risk  register. 

12.2.1.6  Make-or-Buy  Decisions 

Described  in  Section  12.1 .3.5.  Organizations  procuring  goods  or  services  analyze  the  need,  identify  resources, 
and  then  compare  procurement  strategies  when  deciding  to  buy.  Organizations  also  evaluate  the  need  of  buying 
products  versus  making  the  items  themselves.  Factors  that  influence  make-or-buy  decisions  may  include: 

• Core  capabilities  of  the  organization, 

• Value  delivered  by  vendors  meeting  the  need, 

• Risks  associated  with  meeting  the  need  in  a cost-effective  manner,  and 

• Capability  internally  compared  with  the  vendor  community. 

12.2.1.7  Procurement  Statement  of  Work 

Described  in  Section  1 2.1 .3.2.  The  procurement  statement  of  work  provides  suppliers  with  a clearly  stated  set 
of  goals,  requirements,  and  outcomes  from  which  they  can  provide  a quantifiable  response.  The  statement  of  work 
is  a critical  component  of  the  procurement  process  and  can  be  modified  as  needed  through  this  process  until  a final 
agreement  is  in  place.  The  statements  of  work  may  include,  but  are  not  limited  to: 

• Specifications, 

• Quantity  desired, 

• Quality  levels, 

• Performance  data, 

• Period  of  performance, 

• Work  location,  and 

• Other  requirements. 
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12.2.1.8  Organizational  Process  Assets 

Described  in  Section  2.1 .4.  Elements  of  the  organizational  process  assets  that  can  influence  the  Conduct 
Procurements  process  include,  but  are  not  limited  to: 

• Listings  of  prospective  and  previously  qualified  sellers, 

• Information  on  relevant  past  experience  with  sellers,  both  good  and  bad,  and 

• Prior  agreements. 

Whenever  a prior  agreement  is  in  place,  the  buyer  and  seller  roles  will  have  already  been  decided  by  executive 
management.  In  some  cases,  the  seller  may  already  be  working  under  a contract  funded  by  the  buyer  or  jointly  by 
both  parties.  The  effort  of  the  buyer  and  seller  in  this  process  is  to  collectively  prepare  a procurement  statement 
of  work  that  will  satisfy  the  requirements  of  the  project.  The  parties  will  then  negotiate  a final  contract  for  award. 


12.2.2  Conduct  Procurements:  Tools  and  Techniques 


12.2.2.1  Bidder  Conferences 

Bidder  conferences  (sometimes  called  contractor  conferences,  vendor  conferences,  and  pre-bid  conferences) 
are  meetings  between  the  buyer  and  all  prospective  sellers  prior  to  submittal  of  a bid  or  proposal.  They  are  used 
to  ensure  that  all  prospective  sellers  have  a clear  and  common  understanding  of  the  procurement  requirements), 
and  that  no  bidders  receive  preferential  treatment.  To  be  fair,  buyers  should  take  great  care  to  ensure  that  all 
prospective  sellers  hear  every  question  from  any  individual  prospective  seller  and  every  answer  from  the  buyer. 
Typically  fairness  is  addressed  by  techniques  such  as  collecting  questions  from  bidders  or  arranging  field  visits  in 
advance  of  the  bidder  conference.  Responses  to  questions  can  be  incorporated  into  the  procurement  documents 
as  amendments. 


12.2.2.2  Proposal  Evaluation  Techniques 

On  complex  procurements,  where  source  selection  will  be  made  based  on  seller  responses  to  previously  defined 
weighted  criteria,  a formal  evaluation  review  process  will  be  defined  by  the  buyer’s  procurement  policies.  The 
evaluation  committee  will  make  their  selection  for  approval  by  management  prior  to  the  award. 
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12.2.2.3  Independent  Estimates 

For  many  procurement  items,  the  procuring  organization  may  elect  to  either  prepare  its  own  independent 
estimate,  or  have  an  estimate  of  costs  prepared  by  an  outside  professional  estimator,  to  serve  as  a benchmark  on 
proposed  responses.  Significant  differences  in  cost  estimates  can  be  an  indication  that  the  procurement  statement 
of  work  was  deficient,  ambiguous,  and/or  that  the  prospective  sellers  either  misunderstood  or  failed  to  respond  fully 
to  the  procurement  statement  of  work. 

12.2.2.4  Expert  Judgment 

Expert  judgment  may  be  used  in  evaluating  seller  proposals.  The  evaluation  of  proposals  may  be  accomplished 
by  a multi-discipline  review  team  with  expertise  in  each  of  the  areas  covered  by  the  procurement  documents 
and  proposed  contract.  This  can  include  expertise  from  functional  disciplines  such  as  contracting,  legal,  finance, 
accounting,  engineering,  design,  research,  development,  sales,  and  manufacturing. 

12.2.2.5  Advertising 

Existing  lists  of  potential  sellers  often  can  be  expanded  by  placing  advertisements  in  general  circulation 
publications  such  as  selected  newspapers  or  in  specialty  trade  publications.  Some  organizations  use  online 
resources  to  communicate  solicitations  to  the  vendor  community.  Some  government  jurisdictions  require  public 
advertising  of  certain  types  of  procurement  items,  and  most  government  jurisdictions  require  public  advertising  or 
online  posting  of  pending  government  contracts. 

12.2.2.6  Analytical  Techniques 

Procurements  involve  defining  a need  in  such  a way  that  vendors  can  bring  value  through  their  offerings.  To 
ensure  that  the  need  can  be  and  is  met,  analytical  techniques  can  help  organizations  identify  the  readiness  of  a 
vendor  to  provide  the  desired  end  state,  determine  the  cost  expected  to  support  budgeting,  and  avoid  cost  overruns 
due  to  changes.  By  examining  past  performance  information,  teams  may  identify  areas  that  may  have  more  risk 
and  that  need  to  be  monitored  closely  to  ensure  success  of  the  project. 
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12.2.2.7  Procurement  Negotiations 

Procurement  negotiations  clarify  the  structure,  requirements,  and  other  terms  of  the  purchases  so  that  mutual 
agreement  can  be  reached  prior  to  signing  the  contract.  Final  contract  language  reflects  all  agreements  reached. 
Subjects  covered  should  include  responsibilities,  authority  to  make  changes,  applicable  terms  and  governing  law, 
technical  and  business  management  approaches,  proprietary  rights,  contract  financing,  technical  solutions,  overall 
schedule,  payments,  and  price.  Negotiations  conclude  with  a contract  document  that  can  be  executed  by  both  buyer 
and  seller. 

For  complex  procurement  items,  contract  negotiation  can  be  an  independent  process  with  inputs  (e.g.,  issues  or 
an  open  items  listing)  and  outputs  (e.g.,  documented  decisions)  of  its  own.  For  simple  procurement  items,  the  terms 
and  conditions  of  the  contract  can  be  previously  set  and  nonnegotiable,  and  only  need  to  be  accepted  by  the  seller. 

The  project  manager  may  not  be  the  lead  negotiator  on  procurements.  The  project  manager  and  other  members 
of  the  project  management  team  may  be  present  during  negotiations  to  provide  assistance,  and,  if  needed,  to  add 
clarification  of  the  project’s  technical,  quality,  and  management  requirements. 


12.2.3  Conduct  Procurements:  Outputs 
12.2.3.1  Selected  Sellers 


The  selected  sellers  are  those  who  have  been  judged  to  be  in  a competitive  range  based  upon  the  outcome 
of  the  proposal  or  bid  evaluation,  and  who  have  negotiated  a draft  contract  that  will  become  the  actual  contract 
when  an  award  is  made.  Final  approval  of  all  complex,  high-value,  high-risk  procurements  will  generally  require 
organizational  senior  management  approval  prior  to  award. 


12.2.3.2  Agreements 

A procurement  agreement  includes  terms  and  conditions,  and  may  incorporate  other  items  that  the  buyer 
specifies  regarding  what  the  seller  is  to  perform  or  provide.  It  is  the  project  management  team’s  responsibility 
to  make  certain  that  all  agreements  meet  the  specific  needs  of  the  project  while  adhering  to  organizational 
procurement  policies.  Depending  upon  the  application  area,  an  agreement  can  also  be  called  an  understanding, 
a contract,  a subcontract,  or  a purchase  order.  Regardless  of  the  document’s  complexity,  a contract  is  a mutually 
binding  legal  agreement  that  obligates  the  seller  to  provide  the  specified  products,  services,  or  results,  and 
obligates  the  buyer  to  compensate  the  seller.  A contract  is  a legal  relationship  subject  to  remedy  in  the  courts. 
The  major  components  in  an  agreement  document  will  vary,  but  may  include  the  following: 
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• Statement  of  work  or  deliverables, 

• Schedule  baseline, 

• Performance  reporting, 

• Period  of  performance, 

• Roles  and  responsibilities, 

• Seller’s  place  of  performance, 

• Pricing, 

• Payment  terms, 

• Place  of  delivery, 

• Inspection  and  acceptance  criteria, 

• Warranty, 

• Product  support, 

• Limitation  of  liability, 

• Fees  and  retainer, 

• Penalties, 

• Incentives, 

• Insurance  and  performance  bonds, 

• Subordinate  subcontractor  approvals, 

• Change  request  handling,  and 

• Termination  clause  and  alternative  dispute  resolution  (ADR)  mechanisms.  The  ADR  method  can  be  decided 
in  advance  as  a part  of  the  procurement  award. 

12.2.3.3  Resource  Calendars 

The  quantity  and  availability  of  contracted  resources  and  those  dates  on  which  each  specific  resource  or 
resource  group  can  be  active  or  idle  are  documented. 

12.2.3.4  Change  Requests 

Change  requests  to  the  project  management  plan,  its  subsidiary  plans,  and  other  components  are  processed  for 
review  and  disposition  through  the  Perform  Integrated  Change  Control  process  (Section  4.5). 
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12.2.3.5  Project  Management  Plan  Updates 

Elements  of  the  project  management  plan  that  may  be  updated  include,  but  are  not  limited  to: 

• Cost  baseline, 

• Scope  baseline, 

• Schedule  baseline, 

• Communications  management  plan,  and 

• Procurement  management  plan. 

12.2.3.6  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Requirements  documentation, 

• Requirements  traceability  documentation, 

• Risk  register,  and 

• Stakeholder  register.  12 

12.3  Control  Procurements 

Control  Procurements  is  the  process  of  managing  procurement  relationships,  monitoring  contract  performance, 
and  making  changes  and  corrections  to  contracts  as  appropriate.  The  key  benefit  of  this  process  is  that  it  ensures 
that  both  the  seller’s  and  buyer’s  performance  meets  procurement  requirements  according  to  the  terms  of  the  legal 
agreement.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  12-6.  Figure  12-7 
depicts  the  data  flow  diagram  of  the  process. 


.1  Project  management  plan 
.2  Procurement  documents 
.3  Agreements 
.4  Approved  change 


.1  Contract  change  control 


.2  Procurement 


performance  reviews 
.3  Inspections  and  audits 
.4  Performance  reporting 
.5  Payment  systems 


system 


.1  Work  performance 


information 
.2  Change  requests 
.3  Project  management  plan 


requests 

.5  Work  performance 


updates 

.4  Project  documents 


reports 

.6  Work  performance  data 


.6  Claims  administration 


updates 

.5  Organizational  process 


V 


J .7  Records  management 


assets  updates 


system 


Figure  12-6.  Control  Procurements:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  12-7.  Control  Procurements  Data  Flow  Diagram 

Both  the  buyer  and  the  seller  will  administer  the  procurement  contract  for  similar  purposes.  Each  are  required 
to  ensure  that  both  parties  meet  their  contractual  obligations  and  that  their  own  legal  rights  are  protected.  The  legal 
nature  of  the  contractual  relationship  makes  it  imperative  that  the  project  management  team  is  aware  of  the  legal 
implications  of  actions  taken  when  controlling  any  procurement.  On  larger  projects  with  multiple  providers,  a key 
aspect  of  contract  administration  is  managing  interfaces  among  the  various  providers. 

Due  to  varying  organizational  structures,  many  organizations  treat  contract  administration  as  an  administrative 
function  separate  from  the  project  organization.  While  a procurement  administrator  may  be  on  the  project  team, 
this  individual  typically  reports  to  a supervisor  from  a different  department.  This  is  usually  true  if  the  performing 
organization  is  also  the  seller  of  the  project  to  an  external  customer. 
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Control  Procurements  includes  application  of  the  appropriate  project  management  processes  to  the  contractual 
relationship(s)  and  integration  of  the  outputs  from  these  processes  into  the  overall  management  of  the  project.  This 
integration  will  often  occur  at  multiple  levels  when  there  are  multiple  sellers  and  multiple  products,  services,  or 
results  involved.  The  project  management  processes  that  are  applied  may  include,  but  are  not  limited  to: 

• Direct  and  Manage  Project  Work.  To  authorize  the  seller’s  work  at  the  appropriate  time. 

• Control  Quality.  To  inspect  and  verify  the  adequacy  of  the  seller’s  product. 

• Perform  Integrated  Change  Control.  To  assure  that  changes  are  properly  approved  and  that  all  those 
with  a need  to  know  are  aware  of  such  changes. 

• Control  Risks.  To  ensure  that  risks  are  mitigated. 

Control  Procurements  also  has  a financial  management  component  that  involves  monitoring  payments  to  the 
seller.  This  ensures  that  payment  terms  defined  within  the  contract  are  met  and  that  seller  compensation  is  linked 
to  seller  progress,  as  defined  in  the  contract.  One  of  the  principal  concerns  when  making  payments  to  suppliers  is 
that  there  is  a close  relationship  of  payments  made  to  the  work  accomplished. 

The  Control  Procurements  process  reviews  and  documents  how  well  a seller  is  performing  or  has  performed 
based  on  the  contract  and  establishes  corrective  actions  when  needed.  This  performance  review  may  be  used  as 
a measure  of  the  seller’s  competency  for  performing  similar  work  on  future  projects.  Similar  evaluations  are  also  12 

carried  out  when  it  is  necessary  to  confirm  that  a seller  is  not  meeting  the  seller’s  contractual  obligations  and 
when  the  buyer  contemplates  corrective  actions.  Control  Procurements  includes  capturing  the  necessary  details 
for  managing  any  early  terminations  of  the  contracted  work  (for  cause,  convenience,  or  default)  in  accordance  with 
the  termination  clause  of  the  agreement.  These  details  are  used  in  the  Close  Procurements  process  to  terminate 
the  agreement. 

Agreements  can  be  amended  at  any  time  prior  to  contract  closure  by  mutual  consent,  in  accordance  with  the 
change  control  terms  of  the  agreement.  Such  amendments  are  typically  captured  in  writing. 

12.3.1  Control  Procurements:  Inputs 

12.3.1.1  Project  Management  Plan 

Described  in  Section  4. 2.3.1 . The  project  management  plan  describes  how  the  procurement  processes  will  be 
managed  from  developing  procurement  documentation  through  contract  closure. 
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12.3.1.2  Procurement  Documents 

Described  in  Section  1 2.1 .3.3.  Procurement  documents  contain  complete  supporting  records  for  administration 
of  the  procurement  processes;  this  includes  procurement  contract  awards  and  the  statement  of  work. 

12.3.1.3  Agreements 

Described  in  Section  12.2.3.2.  Agreements  are  understandings  between  parties,  including  understanding  of 
the  duties  of  each  party. 

12.3.1.4  Approved  Change  Requests 

Approved  change  requests  can  include  modifications  to  the  terms  and  conditions  of  the  contract,  including  the 
procurement  statement  of  work,  pricing,  and  descriptions  of  the  products,  services,  or  results  to  be  provided.  All 
procurement-related  changes  are  formally  documented  in  writing  and  approved  before  being  implemented  through 
the  Control  Procurements  process. 

12.3.1.5  Work  Performance  Reports 

Described  in  Section  4.4. 3.2.  Seller  performance-related  documentation  includes: 

• Technical  documentation.  Seller-developed  technical  documentation  and  other  deliverable  information 
are  provided  in  accordance  with  the  terms  of  the  contract. 

• Work  performance  information.  The  seller’s  performance  reports  indicate  which  deliverables  have 
been  completed  and  which  have  not. 

12.3.1.6  Work  Performance  Data 

Described  in  Section  4. 3. 3. 2.  Work  performance  data  includes  (1 ) the  extent  to  which  quality  standards  are 
being  satisfied,  (2)  the  costs  that  have  been  incurred  or  committed,  and  (3)  identification  of  the  seller  invoices 
that  have  been  paid.  All  data  are  collected  as  part  of  project  execution. 
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12.3.2  Control  Procurements:  Tools  and  Techniques 

12.3.2.1  Contract  Change  Control  System 

A contract  change  control  system  defines  the  process  by  which  the  procurement  can  be  modified.  It  includes 
the  paperwork,  tracking  systems,  dispute  resolution  procedures,  and  approval  levels  necessary  for  authorizing 
changes.  The  contract  change  control  system  is  integrated  with  the  integrated  change  control  system. 

12.3.2.2  Procurement  Performance  Reviews 

A procurement  performance  review  is  a structured  review  of  the  seller’s  progress  to  deliver  project  scope 
and  quality,  within  cost  and  on  schedule,  as  compared  to  the  contract.  It  can  include  a review  of  seller-prepared 
documentation  and  buyer  inspections,  as  well  as  quality  audits  conducted  during  seller’s  execution  of  the  work. 
The  objective  of  a performance  review  is  to  identify  performance  successes  or  failures,  progress  with  respect  to 
the  procurement  statement  of  work,  and  contract  noncompliance,  which  allow  the  buyer  to  quantify  the  seller’s 
demonstrated  ability  or  inability  to  perform  work.  Such  reviews  may  take  place  as  a part  of  project  status  reviews, 
which  would  include  key  suppliers. 

12.3.2.3  Inspections  and  Audits 

Inspections  and  audits  required  by  the  buyer  and  supported  by  the  seller,  as  specified  in  the  procurement 
contract,  can  be  conducted  during  execution  of  the  project  to  verify  compliance  in  the  seller’s  work  processes  or 
deliverables.  If  authorized  by  contract,  some  inspection  and  audit  teams  can  include  buyer  procurement  personnel. 

12.3.2.4  Performance  Reporting 

Work  performance  data  and  reports  supplied  by  sellers  are  evaluated  against  the  agreement  requirements. 
Work  performance  information  from  this  evaluation  is  then  reported  as  appropriate.  Performance  reporting  provides 
management  with  information  about  how  effectively  the  seller  is  achieving  the  contractual  objectives. 

12.3.2.5  Payment  Systems 

Payments  to  the  seller  are  typically  processed  by  the  accounts  payable  system  of  the  buyer  after 
certification  of  satisfactory  work  by  an  authorized  person  on  the  project  team.  All  payments  should  be  made 
and  documented  in  strict  accordance  with  the  terms  of  the  contract. 
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12.3.2.6  Claims  Administration 

Contested  changes  and  potential  constructive  changes  are  those  requested  changes  where  the  buyer  and  seller 
cannot  reach  an  agreement  on  compensation  for  the  change  or  cannot  agree  that  a change  has  occurred.  These 
contested  changes  are  variously  called  claims,  disputes,  or  appeals.  Claims  are  documented,  processed,  monitored, 
and  managed  throughout  the  contract  life  cycle,  usually  in  accordance  with  the  terms  of  the  contract.  If  the  parties 
themselves  do  not  resolve  a claim,  it  may  have  to  be  handled  in  accordance  with  alternative  dispute  resolution 
(ADR)  typically  following  procedures  established  in  the  contract.  Settlement  of  all  claims  and  disputes  through 
negotiation  is  the  preferred  method. 

12.3.2.7  Records  Management  System 

A records  management  system  is  used  by  the  project  manager  to  manage  contract  and  procurement 
documentation  and  records.  It  consists  of  a specific  set  of  processes,  related  control  functions,  and  automation 
tools  that  are  consolidated  and  combined  as  part  of  the  project  management  information  system  (Section  4. 4.2. 3). 
The  system  contains  a retrievable  archive  of  contract  documents  and  correspondence. 

12.3.3  Control  Procurements:  Outputs 
12.3.3.1  Work  Performance  Information 

Work  performance  information  provides  a basis  for  identification  of  current  or  potential  problems  to  support  later 
claims  or  new  procurements.  By  reporting  on  the  performance  of  a vendor,  the  organization  increases  knowledge 
of  the  performance  of  the  procurement,  which  supports  improved  forecasting,  risk  management,  and  decision 
making.  Performance  reports  also  assist  in  the  event  there  is  a dispute  with  the  vendor. 

Work  performance  information  includes  reporting  compliance  of  contracts,  which  provides  procuring 
organizations  a mechanism  to  track  specific  deliverables  expected  and  received  from  vendors.  Contract  compliance 
reports  support  improved  communications  with  vendors  so  that  potential  issues  are  addressed  promptly  to  the 
satisfaction  of  all  parties. 
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12.3.3.2  Change  Requests 

Change  requests  to  the  project  management  plan,  its  subsidiary  plans,  and  other  components,  such  as  the 
cost  baseline,  schedule  baseline,  and  procurement  management  plan,  may  result  from  the  Control  Procurements 
process.  Change  requests  are  processed  for  review  and  approval  through  the  Perform  Integrated  Change  Control 
process. 

Requested  but  unresolved  changes  can  include  direction  provided  by  the  buyer  or  actions  taken  by  the  seller, 
which  the  other  party  considers  a constructive  change  to  the  contract.  Since  any  of  these  constructive  changes  may 
be  disputed  by  one  party  and  can  lead  to  a claim  against  the  other  party,  such  changes  are  uniquely  identified  and 
documented  by  project  correspondence. 


12.3.3.3  Project  Management  Plan  Updates 

Elements  of  the  project  management  plan  that  may  be  updated  include,  but  are  not  limited  to: 

• Procurement  management  plan.  The  procurement  management  plan  is  updated  to  reflect  any  approved 
change  requests  that  affect  procurement  management,  including  impacts  to  costs  or  schedules. 

• Schedule  baseline.  If  there  are  slippages  that  impact  overall  project  performance,  the  schedule  baseline 
may  need  to  be  updated  to  reflect  the  current  expectations. 

• Cost  baseline.  If  there  are  changes  that  impact  overall  project  costs,  the  cost  baseline  may  need  to  be 
updated  to  reflect  the  current  expectations. 


12.3.3.4  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to,  procurement  documentation. 
Procurement  documentation  may  include  the  procurement  contract  with  all  supporting  schedules,  requested 
unapproved  contract  changes,  and  approved  change  requests.  Procurement  documentation  also  includes  any 
seller-developed  technical  documentation  and  other  work  performance  information,  such  as  deliverables,  seller 
performance  reports  and  warranties,  financial  documents  including  invoices  and  payment  records,  and  the 
results  of  contract-related  inspections. 


12.3.3.5  Organizational  Process  Assets  Updates 

Elements  of  the  organizational  process  assets  that  may  be  updated  include,  but  are  not  limited  to: 
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• Correspondence.  Contractterms  and  conditions  often  require  written  documentation  of  certain  aspects  of 
buyer/seller  communications,  such  as  the  need  for  warnings  of  unsatisfactory  performance  and  requests 
for  contract  changes  or  clarification.  This  can  include  the  reported  results  of  buyer  audits  and  inspections 
that  indicate  weaknesses  the  seller  needs  to  correct.  In  addition  to  specific  contract  requirements  for 
documentation,  a complete  and  accurate  written  record  of  all  written  and  oral  contract  communications, 
as  well  as  actions  taken  and  decisions  made,  are  maintained  by  both  parties. 

• Payment  schedules  and  requests.  All  payments  should  be  made  in  accordance  with  the  procurement 
contract  terms  and  conditions. 

• Seller  performance  evaluation  documentation.  Seller  performance  evaluation  documentation  is 
prepared  by  the  buyer.  Such  performance  evaluations  document  the  seller’s  ability  to  continue  to  perform 
work  on  the  current  contract,  indicate  if  the  seller  can  be  allowed  to  perform  work  on  future  projects, 
or  rate  how  well  the  seller  is  performing  the  project  work.  These  documents  may  form  the  basis  for 
early  termination  of  the  seller’s  contract  or  determine  how  contract  penalties,  fees,  or  incentives  are 
administered.  The  results  of  these  performance  evaluations  can  also  be  included  in  the  appropriate 
qualified  seller  lists. 

12.4  Close  Procurements 

Close  Procurements  is  the  process  of  completing  each  procurement.  The  key  benefit  of  this  process  is  that 
it  documents  agreements  and  related  documentation  for  future  reference.  The  inputs,  tools  and  techniques,  and 
outputs  of  this  process  are  depicted  in  Figure  1 2-8.  Figure  1 2-9  depicts  the  data  flow  diagram  of  the  process. 
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Figure  12-8.  Close  Procurements:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  12-9.  Close  Procurements  Data  Flow  Diagram 

The  Close  Procurements  process  also  involves  administrative  activities  such  as  finalizing  open  claims,  updating 
records  to  reflect  final  results,  and  archiving  such  information  for  future  use.  Close  Procurements  addresses  each 
contract  applicable  to  the  project  or  a project  phase.  In  multiphase  projects,  the  term  of  a contract  may  only  be 
applicable  to  a given  phase  of  the  project.  In  these  cases,  the  Close  Procurements  process  closes  the  procurement(s) 
applicable  to  that  phase  of  the  project.  Unresolved  claims  may  be  subject  to  litigation  after  closure.  The  contract 
terms  and  conditions  can  prescribe  specific  procedures  for  agreement  closure.  The  Close  Procurements  process 
supports  the  Close  Project  or  Phase  process  (Section  4.6)  by  ensuring  contractual  agreements  are  completed  or 
terminated. 

Early  termination  of  a contract  is  a special  case  of  procurement  closure  that  can  result  from  a mutual  agreement 
by  both  parties,  from  the  default  of  one  party,  or  for  convenience  of  the  buyer  if  provided  for  in  the  contract.  The 
rights  and  responsibilities  of  the  parties  in  the  event  of  an  early  termination  are  contained  in  the  terminations  clause 
of  the  contract.  Based  upon  those  procurement  terms  and  conditions,  the  buyer  may  have  the  right  to  terminate 
the  whole  contract  or  a portion  of  the  contract,  at  any  time,  for  cause  or  convenience.  However,  based  upon  those 
contract  terms  and  conditions,  the  buyer  may  have  to  compensate  the  seller  for  seller’s  preparations  and  for  any 
completed  and  accepted  work  related  to  the  terminated  part  of  the  contract. 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK®  Guide)  - Fifth  Edition 


387 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


12  - PROJECT  PROCUREMENT  MANAGEMENT 


12.4.1  Close  Procurements:  Inputs 

12.4.1.1  Project  Management  Plan 

Described  in  Section  4. 2.3.1  .The  project  management  plan  contains  the  procurement  management  plan,  which 
provides  the  details  and  guidelines  for  closing  out  procurements. 

12.4.1.2  Procurement  Documents 

To  close  the  contract,  all  procurement  documentation  is  collected,  indexed,  and  filed.  Information  on  contract 
schedule,  scope,  quality,  and  cost  performance  along  with  all  contract  change  documentation,  payment  records, 
and  inspection  results  are  cataloged.  This  information  can  be  used  for  lessons  learned  information  and  as  a basis 
for  evaluating  contractors  for  future  contracts. 

12.4.2  Close  Procurements:  Tools  and  Techniques 

12.4.2.1  Procurement  Audits 

A procurement  audit  is  a structured  review  of  the  procurement  process  originating  from  the  Plan  Procurement 
Management  process  through  Control  Procurements.  The  objective  of  a procurement  audit  is  to  identify  successes 
and  failures  that  warrant  recognition  in  the  preparation  or  administration  of  other  procurement  contracts  on  the 
project,  or  on  other  projects  within  the  performing  organization. 

12.4.2.2  Procurement  Negotiations 

In  all  procurement  relationships,  the  final  equitable  settlement  of  all  outstanding  issues,  claims,  and  disputes  by 
negotiation  is  a primary  goal.  Whenever  settlement  cannot  be  achieved  through  direct  negotiation,  some  form  of 
alternative  dispute  resolution  (ADR)  including  mediation  or  arbitration  may  be  explored.  When  all  else  fails,  litigation 
in  the  courts  is  the  least  desirable  option. 
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12.4.2.3  Records  Management  System 

Described  in  Section  12.3.2.7.  A records  management  system  is  used  by  the  project  manager  to  manage 
contract  and  procurement  documentation  and  records.  Contract  documents  and  correspondence  are  archived 
through  the  records  management  system  as  part  of  the  Close  Procurements  process. 


12.4.3  Close  Procurements:  Outputs 


12.4.3.1  Closed  Procurements 

The  buyer,  usually  through  its  authorized  procurement  administrator,  provides  the  seller  with  formal  written 
notice  that  the  contract  has  been  completed.  Requirements  for  formal  procurement  closure  are  usually  defined  in 
the  terms  and  conditions  of  the  contract  and  are  included  in  the  procurement  management  plan. 


12.4.3.2  Organizational  Process  Assets  Updates 

Elements  of  the  organizational  process  assets  that  may  be  updated  include,  but  are  not  limited  to: 

• Procurement  file.  A complete  set  of  indexed  contract  documentation,  including  the  closed  contract,  is 
prepared  for  inclusion  with  the  final  project  files. 

• Deliverable  acceptance.  Documentation  of  formal  acceptance  of  seller-provided  deliverables  may  be 
required  to  be  retained  by  the  organization.  The  Close  Procurement  process  ensures  this  documentation 
requirement  is  satisfied.  Requirements  for  formal  deliverable  acceptance  and  how  to  address 
nonconforming  deliverables  are  usually  defined  in  the  agreement. 

• Lessons  learned  documentation.  Lessons  learned,  what  has  been  experienced,  and  process 
improvement  recommendations,  should  be  developed  for  the  project  file  to  improve  future  procurements. 
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13 

PROJECT  STAKEHOLDER  MANAGEMENT 


Project  Stakeholder  Management  includes  the  processes  required  to  identify  the  people,  groups,  or 
organizations  that  could  impact  or  be  impacted  by  the  project,  to  analyze  stakeholder  expectations  and  their 
impact  on  the  project,  and  to  develop  appropriate  management  strategies  for  effectively  engaging  stakeholders 
in  project  decisions  and  execution.  Stakeholder  management  also  focuses  on  continuous  communication  with 
stakeholders  to  understand  their  needs  and  expectations,  addressing  issues  as  they  occur,  managing  conflicting 
interests  and  fostering  appropriate  stakeholder  engagement  in  project  decisions  and  activities.  Stakeholder 
satisfaction  should  be  managed  as  a key  project  objective. 

Figure  1 3-1  provides  an  overview  of  the  Project  Stakeholder  Management  processes  that  include  the  following: 

13.1  Identify  Stakeholders — The  process  of  identifying  the  people,  groups,  or  organizations  that 
could  impact  or  be  impacted  by  a decision,  activity,  or  outcome  of  the  project;  and  analyzing  and 
documenting  relevant  information  regarding  their  interests,  involvement,  interdependencies, 
influence,  and  potential  impact  on  project  success. 

13.2  Plan  Stakeholder  Management — The  process  of  developing  appropriate  management  strategies  to 
effectively  engage  stakeholders  throughout  the  project  life  cycle,  based  on  the  analysis  of  their  needs, 
interests,  and  potential  impact  on  project  success. 

13.3  Manage  Stakeholder  Engagement — The  process  of  communicating  and  working  with  stakeholders 
to  meet  their  needs/expectations,  address  issues  as  they  occur,  and  foster  appropriate  stakeholder 
engagement  in  project  activities  throughout  the  project  life  cycle. 

13.4  Control  Stakeholder  Engagement — The  process  of  monitoring  overall  project  stakeholder 
relationships  and  adjusting  strategies  and  plans  for  engaging  stakeholders. 

These  processes  interact  with  each  other  and  with  processes  in  other  Knowledge  Areas  as  described  in  detail 
in  Section  3 and  Annex  A1. 

Every  project  will  have  stakeholders  who  are  impacted  by  or  can  impact  the  project  in  a positive  or  negative  way. 
While  some  stakeholders  may  have  a limited  ability  to  influence  the  project,  others  may  have  significant  influence 
on  the  project  and  its  expected  outcomes.  The  ability  of  the  project  manager  to  correctly  identify  and  manage  these 
stakeholders  in  an  appropriate  manner  can  mean  the  difference  between  success  and  failure. 
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Figure  13-1.  Project  Stakeholder  Management  Overview 
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13.1  Identify  Stakeholders 

Identify  Stakeholders  is  the  process  of  identifying  the  people,  groups,  or  organizations  that  could  impact  or 
be  impacted  by  a decision,  activity,  or  outcome  of  the  project,  analyzing  and  documenting  relevant  information 
regarding  their  interests,  involvement,  interdependencies,  influence,  and  potential  impact  on  project  success.  The 
key  benefit  of  this  process  is  that  it  allows  the  project  manager  to  identify  the  appropriate  focus  for  each  stakeholder 
or  group  of  stakeholders.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  1 3-2. 
Figure  1 3-3  depicts  the  data  flow  diagram  of  the  process. 
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Figure  13-2.  Identify  Stakeholders:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  13-3.  Identify  Stakeholders  Data  Flow  Diagram 
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Project  stakeholders  are  individuals,  groups,  or  organizations  who  may  affect,  be  affected  by,  or  perceive 
themselves  to  be  affected  by  a decision,  activity,  or  outcome  of  a project.  They  are  comprised  of  persons  and 
organizations  such  as  customers,  sponsors,  the  performing  organization,  and  the  public  who  are  actively  involved 
in  the  project,  or  whose  interests  may  be  positively  or  negatively  affected  by  the  execution  or  completion  of  the 
project.  They  may  also  exert  influence  over  the  project  and  its  deliverables.  Stakeholders  may  be  at  different 
levels  within  the  organization  and  may  possess  different  authority  levels,  or  may  be  external  to  the  performing 
organization  for  the  project.  Section  1 3.1 .2.1  identifies  various  types  of  project  stakeholders. 

It  is  critical  for  project  success  to  identify  the  stakeholders  early  in  the  project  or  phase  and  to  analyze  their 
levels  of  interest,  their  individual  expectations,  as  well  as  their  importance  and  influence.  This  initial  assessment 
should  be  reviewed  and  updated  regularly.  Most  projects  will  have  a diverse  number  of  stakeholders  depending 
on  their  size,  type,  and  complexity.  While  the  project  manager’s  time  is  limited  and  should  be  used  as  efficiently 
as  possible,  these  stakeholders  should  be  classified  according  to  their  interest,  influence,  and  involvement  in  the 
project,  taking  into  consideration  the  fact  that  the  affect  or  influence  of  a stakeholder  may  not  occur  or  become 
evident  until  later  stages  in  the  project  or  phase.  This  enables  the  project  manager  to  focus  on  the  relationships 
necessary  to  ensure  the  success  of  the  project. 

13.1.1  Identify  Stakeholders:  Inputs 

13.1.1.1  Project  Charter 

Described  in  Section  4.1 .3.1 . The  project  charter  can  provide  information  about  internal  and  external  parties 
related  with  the  project  and  affected  by  the  result  or  the  execution  of  the  project,  such  as  project  sponsor(s), 
customers,  team  members,  groups  and  departments  participating  in  the  project,  and  other  people  or  organizations 
affected  by  the  project. 

13.1.1.2  Procurement  Documents 

Described  in  Section  12.1 .3.3.  If  a project  is  the  result  of  a procurement  activity  or  is  based  on  an  established 
contract,  the  parties  in  that  contract  are  key  project  stakeholders.  Other  relevant  parties,  such  as  suppliers,  should 
also  be  considered  as  part  of  the  project  stakeholder  list. 
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13.1.1.3  Enterprise  Environmental  Factors 

Described  in  Section  2.1.5.  The  enterprise  environmental  factors  that  can  influence  the  Identify  Stakeholders 
process  include,  but  are  not  limited  to: 

• Organizational  culture  and  structure; 

• Governmental  or  industry  standards  (e.g.,  regulations,  product  standards);  and 

• Global,  regional  or  local  trends,  and  practices  or  habits. 

13.1.1.4  Organizational  Process  Assets 

Described  in  Section  2.1.4.  The  organizational  process  assets  that  can  influence  the  Identify  Stakeholders 
process  include,  but  are  not  limited  to: 

• Stakeholder  register  templates, 

• Lessons  learned  from  previous  projects  or  phases,  and 

• Stakeholder  registers  from  previous  projects. 


13.1.2  Identify  Stakeholders:  Tools  and  Techniques 
13.1.2.1  Stakeholder  Analysis 

Stakeholder  analysis  is  a technique  of  systematically  gathering  and  analyzing  quantitative  and  qualitative 
information  to  determine  whose  interests  should  be  taken  into  account  throughout  the  project.  It  identifies  the 
interests,  expectations,  and  influence  of  the  stakeholders  and  relates  them  to  the  purpose  of  the  project.  It  also 
helps  to  identify  stakeholder  relationships  (with  the  project  and  with  other  stakeholders)  that  can  be  leveraged 
to  build  coalitions  and  potential  partnerships  to  enhance  the  project’s  chance  of  success,  along  with  stakeholder 
relationships  that  need  to  be  influenced  differently  at  different  stages  of  the  project  or  phase. 
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Stakeholder  analysis  generally  follows  the  steps  described  below: 

• Identify  all  potential  project  stakeholders  and  relevant  information,  such  as  their  roles,  departments, 
interests,  knowledge,  expectations,  and  influence  levels.  Key  stakeholders  are  usually  easy  to  identify. 
They  include  anyone  in  a decision-making  or  management  role  who  is  impacted  by  the  project  outcome, 
such  as  the  sponsor,  the  project  manager,  and  the  primary  customer.  Identifying  other  stakeholders  is 
usually  done  by  interviewing  identified  stakeholders  and  expanding  the  list  until  all  potential  stakeholders 
are  included. 

• Analyze  the  potential  impact  or  support  each  stakeholder  could  generate,  and  classify  them  so  as  to  define 
an  approach  strategy.  In  large  stakeholder  communities,  it  is  important  to  prioritize  the  stakeholders  to 
ensure  the  efficient  use  of  effort  to  communicate  and  manage  their  expectations. 

• Assess  how  key  stakeholders  are  likely  to  react  or  respond  in  various  situations,  in  order  to  plan  how  to 
influence  them  to  enhance  their  support  and  mitigate  potential  negative  impacts. 

There  are  multiple  classification  models  used  for  stakeholders  analysis,  such  as: 

• Power/interest  grid,  grouping  the  stakeholders  based  on  their  level  of  authority  (“power”)  and  their  level 
or  concern  (“interest”)  regarding  the  project  outcomes; 

• Power/influence  grid,  grouping  the  stakeholders  based  on  their  level  of  authority  (“power”)  and  their 
active  involvement  (“influence”)  in  the  project; 

• Influence/impact  grid,  grouping  the  stakeholders  based  on  their  active  involvement  (“influence”)  in  the 
project  and  their  ability  to  effect  changes  to  the  project’s  planning  or  execution  (“impact”);  and 

• Salience  model,  describing  classes  of  stakeholders  based  on  their  power  (ability  to  impose  their  will), 
urgency  (need  for  immediate  attention),  and  legitimacy  (their  involvement  is  appropriate). 

Figure  13-4  presents  an  example  of  a power/interest  grid  with  A-H  representing  the  placement  of  generic 
stakeholders. 
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13.1.2.2  Expert  Judgment 

To  ensure  comprehensive  identification  and  listing  of  stakeholders,  judgment  and  expertise  should  be  sought 
from  groups  or  individuals  with  specialized  training  or  subject  matter  expertise,  such  as: 

• Senior  management; 

• Other  units  within  the  organization; 

• Identified  key  stakeholders; 
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• Project  managers  who  have  worked  on  projects  in  the  same  area  (directly  or  through  lessons  learned); 

• Subject  matter  experts  (SMEs)  in  the  business  or  project  area; 

• Industry  groups  and  consultants;  and 

• Professional  and  technical  associations,  regulatory  bodies,  and  nongovernmental  organizations  (NGOs). 

Expert  judgment  can  be  obtained  through  individual  consultations  (one-on-one  meetings,  interviews,  etc.)  or 
through  a panel  format  (focus  groups,  surveys,  etc.). 

13.1.2.3  Meetings 

Profile  analysis  meetings  are  project  meetings  designed  to  develop  an  understanding  of  major  project 
stakeholders,  and  they  can  be  used  to  exchange  and  analyze  information  about  roles,  interests,  knowledge,  and  the 
overall  position  of  each  stakeholder  facing  the  project. 

13.1.3  Identify  Stakeholders:  Outputs 
13.1.3.1  Stakeholder  Register 

The  main  output  of  the  Identify  Stakeholders  process  is  the  stakeholder  register.  This  contains  all  details  related 
to  the  identified  stakeholders  including,  but  not  limited  to: 

• Identification  information.  Name,  organizational  position,  location,  role  in  the  project,  contact 
information; 

• Assessment  information.  Major  requirements,  main  expectations,  potential  influence  in  the  project, 
phase  in  the  life  cycle  with  the  most  interest;  and 

• Stakeholder  classification.  Internal/external,  supporter/neutral/resistor,  etc. 

The  stakeholder  register  should  be  consulted  and  updated  on  a regular  basis,  as  stakeholders  may  change — or 
new  ones  identified — throughout  the  life  cycle  of  the  project. 
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13.2  Plan  Stakeholder  Management 

Plan  Stakeholder  Management  is  the  process  of  developing  appropriate  management  strategies  to  effectively 
engage  stakeholders  throughout  the  project  life  cycle,  based  on  the  analysis  of  their  needs,  interests,  and  potential 
impact  on  project  success.  The  key  benefit  of  this  process  is  that  it  provides  a clear,  actionable  plan  to  interact  with 
project  stakeholders  to  support  the  project’s  interests.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process 
are  depicted  in  Figure  1 3-5.  Figure  1 3-6  depicts  the  data  flow  diagram  of  the  process. 
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Figure  13-5.  Plan  Stakeholder  Management:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  13-6.  Plan  Stakeholder  Management  Data  Flow  Diagram 
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Plan  Stakeholder  Management  identifies  how  the  project  will  affect  stakeholders,  which  then  allows  the 
project  manager  to  develop  various  ways  to  effectively  engage  stakeholders  in  the  project,  to  manage  their 
expectations,  and  to  ultimately  achieving  the  project  objectives.  Stakeholder  management  is  more  than  improving 
communications  and  requires  more  than  managing  a team.  Stakeholder  management  is  about  creation  and 
maintenance  of  relationships  between  the  project  team  and  stakeholders,  with  the  aim  to  satisfy  their  respective 
needs  and  requirements  within  project  boundaries. 

This  process  generates  the  stakeholder  management  plan,  which  contains  detailed  plans  on  how  effective 
stakeholder  management  can  be  realized.  As  the  project  progresses,  the  membership  of  the  stakeholder  community 
and  required  level  of  engagement  may  change,  therefore,  stakeholder  management  planning  is  an  iterative  process 
that  is  reviewed  on  a regular  basis  by  the  project  manager. 

13.2.1  Plan  Stakeholder  Management:  Inputs 

13.2.1.1  Project  Management  Plan 

Described  in  Section  4. 2.3.1.  The  information  used  for  the  development  of  the  stakeholder  management  plan 
includes,  but  is  not  limited  to: 

• Life  cycle  selected  for  the  project  and  the  processes  that  will  be  applied  to  each  phase; 

• Description  of  how  work  will  be  executed  to  accomplish  the  project  objectives; 

• Description  of  how  human  resources  requirements  will  be  met  and  how  roles  and  responsibilities, 
reporting  relationships,  and  staffing  management  will  be  addressed  and  structured  for  the  project; 

• Change  management  plan  that  documents  how  changes  will  be  monitored  and  controlled;  and 

• Need  and  techniques  for  communication  among  stakeholders. 

13.2.1.2  Stakeholder  Register 

Described  in  Section  13.1.3.1.  The  stakeholder  register  provides  the  information  needed  to  plan  appropriate 
ways  to  engage  project  stakeholders. 
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13.2.1.3  Enterprise  Environmental  Factors 

Described  in  Section  2.1.5.  All  enterprise  environmental  factors  are  used  as  inputs  to  this  process,  because 
the  management  of  stakeholders  should  be  adapted  to  the  project  environment.  Of  these,  organizational  culture, 
structure,  and  political  climate  are  of  particular  importance,  because  they  help  in  determining  the  best  options  to 
support  a better  adaptive  process  for  managing  stakeholders. 

13.2.1.4  Organizational  Process  Assets 

Described  in  Section  2.1.4.  All  organizational  process  assets  are  used  as  inputs  for  the  Plan  Stakeholder 
Management  process.  Of  these,  lessons  learned  database  and  historical  information  are  of  particular  importance, 
because  they  provide  insights  on  previous  stakeholder  management  plans  and  their  effectiveness.  These  can  be 
used  to  plan  the  stakeholder  management  activities  for  the  current  project. 


13.2.2  Plan  Stakeholder  Management:  Tools  and  Techniques 


13.2.2.1  Expert  Judgment 

Based  on  the  project  objectives,  the  project  manager  should  apply  expert  judgment  to  decide  upon  the  level  of 
engagement  required  at  each  stage  of  the  project  from  each  stakeholder.  For  example,  at  the  beginning  of  a project, 
it  may  be  necessary  for  senior  stakeholders  to  be  highly  engaged  in  order  to  clear  away  any  obstacles  to  success. 
Once  these  have  been  successfully  removed,  it  may  be  sufficient  for  senior  stakeholders  to  change  their  level  of 
engagement  from  leading  to  supportive,  and  other  stakeholders,  such  as  end  users,  may  become  more  important. 

In  order  to  create  the  stakeholder  management  plan,  judgment  and  expertise  should  be  sought  from  groups 
or  individuals  with  specialized  training  or  subject  matter  expertise  or  insight  into  the  relationships  within  the 
organization,  such  as: 

• Senior  management; 

• Project  team  members; 

• Other  units  or  individuals  within  the  organization; 

• Identified  key  stakeholders; 
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• Project  managers  who  have  worked  on  projects  in  the  same  area  (directly  or  through  lessons  learned); 

• Subject  matter  experts  in  business  or  project  area; 

• Industry  groups  and  consultants;  and 

• Professional  and  technical  associations,  regulatory  bodies,  and  nongovernmental  organization  (NGOs). 

Expert  judgment  can  be  obtained  through  individual  consultations  (one-on-one  meetings,  interviews,  etc.)  or 
through  a panel  format  (focus  groups,  surveys,  etc.). 

13.2.2.2  Meetings 

Meetings  should  be  held  with  experts  and  the  project  team  to  define  the  required  engagement  levels  of  all 
stakeholders.  This  information  can  be  used  to  prepare  the  stakeholder  management  plan. 

13.2.2.3  Analytical  Techniques 

The  current  engagement  level  of  all  stakeholders  needs  to  be  compared  to  the  planned  engagement  levels 
required  for  successful  project  completion.  Stakeholder  engagement  throughout  the  life  cycle  of  the  project  is 
critical  to  project  success. 

The  engagement  level  of  the  stakeholders  can  be  classified  as  follows: 

• Unaware.  Unaware  of  project  and  potential  impacts. 

• Resistant.  Aware  of  project  and  potential  impacts  and  resistant  to  change. 

• Neutral.  Aware  of  project  yet  neither  supportive  nor  resistant. 

• Supportive.  Aware  of  project  and  potential  impacts  and  supportive  to  change. 

• Leading.  Aware  of  project  and  potential  impacts  and  actively  engaged  in  ensuring  the  project  is 
a success. 

The  current  engagement  can  be  documented  using  Stakeholders  Engagement  Assessment  Matrix,  as  shown  in 
Figure  1 3-7,  where  C indicates  the  current  engagement,  and  D indicates  the  desired  engagement.  The  project  team 
needs  to  identify  the  desired  engagement  level  for  the  current  phase  of  the  project,  based  on  available  information. 

The  example  in  Figure  13-7  shows  that  stakeholder  3 is  at  the  desired  engagement  level,  while  stakeholders 
1 and  2 require  further  communications  and  additional  actions  to  move  them  to  the  desired  level  of  engagement. 
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Figure  13-7.  Stakeholders  Engagement  Assessment  Matrix 


Through  this  analytical  process,  gaps  between  the  current  and  desired  engagement  levels  can  be  identified. 
Actions  and  communications  required  to  close  these  gaps  can  be  identified  by  the  project  team  using  expert 
judgment. 


13.2.3  Plan  Stakeholder  Management:  Outputs 


13.2.3.1  Stakeholder  Management  Plan 

The  stakeholder  management  plan  is  a component  of  the  project  management  plan  (Section  4.2. 3.1)  and 
identifies  the  management  strategies  required  to  effectively  engage  stakeholders.  The  stakeholder  management 
plan  can  be  formal  or  informal,  highly  detailed  or  broadly  framed,  based  on  the  needs  of  the  project. 

In  addition  to  the  data  gathered  in  the  stakeholder  register,  the  stakeholder  management  plan  often  provides: 

• Desired  and  current  engagement  levels  of  key  stakeholders; 

• Scope  and  impact  of  change  to  stakeholders; 

• Identified  interrelationships  and  potential  overlap  between  stakeholders; 

• Stakeholder  communication  requirements  for  the  current  project  phase; 

• Information  to  be  distributed  to  stakeholders,  including  language,  format,  content,  and  level  of  detail; 

• Reason  for  the  distribution  of  that  information  and  the  expected  impact  to  stakeholder  engagement; 

• Time  frame  and  frequency  for  the  distribution  of  required  information  to  stakeholders;  and 

• Method  for  updating  and  refining  the  stakeholder  management  plan  as  the  project  progresses  and 
develops. 
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Project  managers  should  be  aware  of  the  sensitive  nature  of  the  stakeholder  management  plan  and  take 
appropriate  precautions.  For  example,  information  on  stakeholders  who  are  resistant  to  the  project  can  be  potentially 
damaging,  and  due  consideration  should  be  given  regarding  the  distribution  of  such  information.  When  updating 
the  stakeholder  management  plan,  the  validity  of  underlying  assumptions  should  be  reviewed  to  ensure  continued 
accuracy  and  relevancy. 

13.2.3.2  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Project  schedule,  and 

• Stakeholder  register. 


13.3  Manage  Stakeholder  Engagement 

Manage  Stakeholder  Engagement  is  the  process  of  communicating  and  working  with  stakeholders  to  meet 
their  needs/expectations,  address  issues  as  they  occur,  and  foster  appropriate  stakeholder  engagement  in  project 
activities  throughout  the  project  life  cycle.  The  key  benefit  of  this  process  is  that  it  allows  the  project  manager 
to  increase  support  and  minimize  resistance  from  stakeholders,  significantly  increasing  the  chances  to  achieve 
project  success.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  1 3-8.  Figure 
1 3-9  depicts  the  data  flow  diagram  of  the  process. 
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Figure  13-8.  Manage  Stakeholder  Engagement:  Inputs,  Tools  & Techniques,  and  Outputs 


404  ©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKB  Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


13  - PROJECT  STAKEHOLDER  MANAGEMENT 


Figure  13-9.  Manage  Stakeholder  Engagement  Data  Flow  Diagram 

Manage  Stakeholder  Engagement  involves  activities  such  as: 

• Engaging  stakeholders  at  appropriate  project  stages  to  obtain  or  confirm  their  continued  commitment  to 
the  success  of  the  project; 

• Managing  stakeholder  expectations  through  negotiation  and  communication,  ensuring  project  goals  are 
achieved; 

• Addressing  potential  concerns  that  have  not  yet  become  issues  and  anticipating  future  problems  that 
may  be  raised  by  stakeholders.  Such  concerns  need  to  be  identified  and  discussed  as  soon  as  possible 
to  assess  associated  project  risks;  and 

• Clarifying  and  resolving  issues  that  have  been  identified. 
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Managing  stakeholder  engagement  helps  to  increase  the  probability  of  project  success  by  ensuring  that 
stakeholders  clearly  understand  the  project  goals,  objectives,  benefits,  and  risks.  This  enables  them  to  be  active 
supporters  of  the  project  and  to  help  guide  activities  and  project  decisions.  By  anticipating  people’s  reactions  to  the 
project,  proactive  actions  can  be  taken  to  win  support  or  minimize  negative  impacts. 

The  ability  of  stakeholders  to  influence  the  project  is  typically  highest  during  the  initial  stages  and 
gets  progressively  lower  as  the  project  progresses.  The  project  manager  is  responsible  for  engaging  and 
managing  the  various  stakeholders  in  a project  and  may  call  upon  the  project  sponsor  to  assist  as  needed. 
Active  management  of  stakeholder  involvement  decreases  the  risk  of  the  project  failing  to  meet  its  goals  and 
objectives. 

13.3.1  Manage  Stakeholder  Engagement:  Inputs 

13.3.1.1  Stakeholder  Management  Plan 

Described  in  Section  13.2.3.1.  The  stakeholder  management  plan  provides  guidance  on  how  the  various 
stakeholders  can  be  best  involved  in  the  project.  The  stakeholder  management  plan  describes  the  methods  and 
technologies  used  for  stakeholder  communication. 

This  plan  is  used  to  determine  the  level  of  interactions  of  various  stakeholders  and — together  with  other 
documents — helps  define  a strategy  for  identifying  and  managing  stakeholders  throughout  the  project  life  cycle. 

13.3.1.2  Communications  Management  Plan 

Described  in  Section  10.1.3.1.  The  communications  management  plan  provides  guidance  and  information  on 
managing  stakeholder  expectations.  The  information  used  includes,  but  is  not  limited  to: 

• Stakeholder  communications  requirements; 

• Information  to  be  communicated,  including  language,  format,  content,  and  level  of  detail; 

• Reason  for  distribution  of  information; 

• Person  or  groups  who  will  receive  information;  and 

• Escalation  process. 
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13.3.1.3  Change  Log 

Described  in  Section  4.5. 3.2.  A change  log  is  used  to  document  changes  that  occur  during  a project.  These 
changes — and  their  impact  on  the  project  in  terms  of  time,  cost,  and  risk — are  communicated  to  the  appropriate 
stakeholders. 

13.3.1.4  Organizational  Process  Assets 

Described  in  Section  2.1.4.  The  organizational  process  assets  that  can  influence  the  Manage  Stakeholder 
Engagement  process  include,  but  are  not  limited  to: 

• Organizational  communication  requirements, 

• Issue  management  procedures, 

• Change  control  procedures,  and 

• Historical  information  about  previous  projects. 

13.3.2  Manage  Stakeholder  Engagement:  Tools  and  Techniques 

13.3.2.1  Communication  Methods  13 

Described  in  Section  10.1.2.4.  The  methods  of  communication  identified  for  each  stakeholder  in  the 
communications  management  plan  are  utilized  during  stakeholder  engagement  management.  Based  on  the 
stakeholders’  communication  requirements,  the  project  manager  decides  how,  when,  and  which  of  these 
communication  methods  are  to  be  used  in  the  project. 

13.3.2.2  Interpersonal  Skills 

The  project  manager  applies  interpersonal  skills  to  manage  stakeholders’  expectations.  For  example: 

• Building  trust, 

• Resolving  conflict, 

• Active  listening,  and 

• Overcoming  resistance  to  change. 
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13.3.2.3  Management  Skills 

The  project  manager  applies  management  skills  to  coordinate  and  harmonize  the  group  toward  accomplishing 
the  project  objectives.  For  example: 

• Facilitate  consensus  toward  project  objectives, 

• Influence  people  to  support  the  project, 

• Negotiate  agreements  to  satisfy  the  project  needs,  and 

• Modify  organizational  behavior  to  accept  the  project  outcomes. 

13.3.3  Manage  Stakeholder  Engagement:  Outputs 

13.3.3.1  Issue  Log 

Managing  stakeholder  engagement  may  result  in  the  development  of  an  issue  log.  This  log  is  updated  as  new 
issues  are  identified  and  current  issues  are  resolved. 

13.3.3.2  Change  Requests 

Managing  stakeholder  engagement  may  result  in  a change  request  to  the  product  or  the  project.  It  may  also 
include  corrective  or  preventive  actions  to  the  project  itself  or  to  the  interaction  with  the  impacted  stakeholders,  as 
appropriate. 

13.3.3.3  Project  Management  Plan  Updates 

Elements  of  the  project  management  plan  that  may  be  updated  include,  but  are  not  limited  to,  the  stakeholder 
management  plan.  This  plan  is  updated  when  new  or  changed  stakeholders  requirements  are  identified.  For 
example,  some  communications  may  no  longer  be  necessary,  an  ineffective  communication  method  may  be 
replaced  by  another  method,  or  a new  communication  requirement  may  be  identified.  It  is  also  updated  as  a result 
of  addressing  concerns  and  resolving  issues.  For  example,  it  may  be  determined  that  a stakeholder  has  additional 
informational  needs. 
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13.3.3.4  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to,  the  stakeholder  register.  This  is  updated 
as  information  on  stakeholders  change,  when  new  stakeholders  are  identified,  or  if  registered  stakeholders  are  no 
longer  involved  in  or  impacted  by  the  project,  or  other  updates  for  specific  stakeholders  are  required. 


13.3.3.5  Organizational  Process  Assets  Updates 

The  organizational  process  assets  that  may  be  updated  include,  but  are  not  limited  to: 

• Stakeholder  notifications.  Information  may  be  provided  to  stakeholders  about  resolved  issues,  approved 
changes,  and  general  project  status. 

• Project  reports.  Formal  and  informal  project  reports  describe  project  status  and  include  lessons  learned, 
issue  logs,  project  closure  reports,  and  outputs  from  other  Knowledge  Areas  (Sections  4-1 2). 

• Project  presentations.  Information  formally  or  informally  provided  by  the  project  team  to  any  or  all 
project  stakeholders. 

• Project  records.  Project  records  include  correspondence,  memos,  meeting  minutes,  and  other 
documents  describing  the  project. 

• Feedback  from  stakeholders.  Information  received  from  stakeholders  concerning  project  operations 
can  be  distributed  and  used  to  modify  or  improve  future  performance  of  the  project. 

• Lessons  learned  documentation.  Documentation  includes  the  root  cause  analysis  of  issues  faced, 
reasoning  behind  the  corrective  action  chosen,  and  other  types  of  lessons  learned  about  stakeholder 
management.  Lessons  learned  are  documented  and  distributed,  and  become  part  of  the  historical 
database  for  both  the  project  and  the  performing  organization. 


13.4  Control  Stakeholder  Engagement 

Control  Stakeholder  Engagement  is  the  process  of  monitoring  overall  project  stakeholder  relationships  and 
adjusting  strategies  and  plans  for  engaging  stakeholders.  The  key  benefit  of  this  process  is  that  it  will  maintain 
or  increase  the  efficiency  and  effectiveness  of  stakeholder  engagement  activities  as  the  project  evolves  and  its 
environment  changes.  The  inputs,  tools  and  techniques,  and  outputs  of  this  process  are  depicted  in  Figure  1 3-1 0. 
Figure  1 3-1 1 depicts  the  data  flow  diagram  of  the  process. 
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Figure  13-10.  Control  Stakeholder  Engagement:  Inputs,  Tools  & Techniques,  and  Outputs 
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Figure  13-11.  Control  Stakeholder  Engagement:  Data  Flow  Diagram 

Stakeholder  engagement  activities  are  included  in  the  stakeholder  management  plan  and  are  executed  during 
the  life  cycle  of  the  project.  Stakeholder  engagement  should  be  continuously  controlled. 
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13.4.1  Control  Stakeholder  Engagement:  Inputs 


13.4.1.1  Project  Management  Plan 

Described  in  Section  4. 2.3.1.  The  project  management  plan  is  used  to  develop  the  stakeholder  management 
plan,  as  described  in  Section  13. 1.3.1.  The  information  used  to  Control  Stakeholder  Engagement  includes,  but  is 
not  limited  to: 

• The  life  cycle  selected  for  the  project  and  the  processes  that  will  be  applied  to  each  phase; 

• How  work  will  be  executed  to  accomplish  the  project  objectives; 

• How  human  resources  requirements  will  be  met,  how  roles  and  responsibilities,  reporting  relationships, 
and  staffing  management  will  be  addressed  and  structured  for  the  project; 

• A change  management  plan  that  documents  how  changes  will  be  monitored  and  controlled;  and 

• Needs  and  techniques  for  communication  among  stakeholders. 


13.4.1.2  Issue  Log 

Described  in  Section  13.3.3.1.  The  issue  log  is  updated  as  new  issues  are  identified  and  current  issues  are 
resolved. 

13.4.1.3  Work  Performance  Data 


Described  in  Section  4. 3. 3. 2.  The  work  performance  data  are  the  primary  observations  and  measurements 
identified  during  activities  being  performed  to  carry  out  the  project  work.  Various  measurements  on  project 
activities  and  deliverables  are  collected  during  various  controlling  processes.  Data  are  often  viewed  as  the 
lowest  level  of  abstraction  from  which  information  is  derived  by  other  processes. 

Examples  of  work  performance  data  include  reported  percentage  of  work  completed,  technical  performance 
measures,  start  and  finish  dates  of  schedule  activities,  number  of  change  requests,  number  of  defects,  actual  costs, 
actual  durations  etc. 


13.4.1.4  Project  Documents 

Multiple  project  documents  originating  from  initiation,  planning,  execution,  or  control  processes  may  be  used  as 
supporting  inputs  for  controlling  stakeholder  engagement.  These  include,  but  are  not  limited  to: 
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• Project  schedule, 

• Stakeholder  register, 

• Issue  log, 

• Change  log,  and 

• Project  communications. 

13.4.2  Control  Stakeholder  Engagement:  Tools  and  Techniques 

13.4.2.1  Information  Management  Systems 

An  information  management  system  provides  a standard  tool  for  the  project  manager  to  capture,  store, 
and  distribute  information  to  stakeholders  about  the  project  cost,  schedule  progress,  and  performance.  It  also 
allows  the  project  manager  to  consolidate  reports  from  several  systems  and  facilitate  report  distribution  to 
the  project  stakeholders.  Examples  of  distribution  formats  may  include  table  reporting,  spreadsheet  analysis, 
and  presentations.  Graphical  capabilities  can  be  used  to  create  visual  representations  of  project  performance 
information. 

13.4.2.2  Expert  Judgment 

To  ensure  comprehensive  identification  and  listing  of  new  stakeholders,  reassessment  of  current  stakeholders 
can  be  performed.  Input  should  be  sought  from  groups  or  individuals  with  specialized  training  or  subject  matter 
expertise,  such  as: 

• Senior  management; 

• Other  units  or  individuals  within  the  organization; 

• Identified  key  stakeholders; 

• Project  managers  who  have  worked  on  projects  in  the  same  area  (directly  or  through  lessons  learned); 

• Subject  matter  experts  in  the  business  or  project  area; 

• Industry  groups  and  consultants;  and 

• Professional  and  technical  associations,  regulatory  bodies,  and  nongovernmental  organizations. 

Expert  judgment  can  be  obtained  through  individual  consultations  (such  as  one-on-one  meetings  or  interviews) 
or  through  a panel  format  (such  as  focus  groups  or  surveys). 
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13.4.2.3  Meetings 

Status  review  meetings  are  used  to  exchange  and  analyze  information  about  stakeholder  engagement. 


13.4.3  Control  Stakeholder  Engagement:  Outputs 


13.4.3.1  Work  Performance  Information 

The  work  performance  information  is  the  performance  data  collected  from  various  controlling  processes, 
analyzed  in  context,  and  integrated  based  on  relationships  across  areas.  Thus  work  performance  data  have  been 
transformed  into  work  performance  information.  Data  per  se  are  not  used  in  the  decision-making  process,  because 
the  meaning  may  be  misinterpreted.  Information,  however,  is  correlated  and  contextualized  and  provides  a sound 
foundation  for  project  decisions. 

Work  performance  information  is  circulated  through  communication  processes.  Examples  of  performance 
information  are  status  of  deliverables,  implementation  status  for  change  requests,  and  forecasted  estimates  to 
complete. 


13.4.3.2  Change  Requests 

Analysis  of  project  performance  and  interactions  with  stakeholders  often  generates  change  requests.  These 
change  requests  are  processed  through  the  Perform  Integrated  Change  Control  process  (Section  4.5)  as  follows: 

• Recommended  corrective  actions  include  changes  that  bring  the  expected  future  performance  of  the 
project  in  line  with  the  project  management  plan;  and 

• Recommended  preventive  actions  can  reduce  the  probability  of  incurring  future  negative  project 
performance. 


13.4.3.3  Project  Management  Plan  Updates 

As  stakeholders  engage  with  the  project  the  overall  effectiveness  of  the  stakeholder  management  strategy 
can  be  evaluated.  As  needed  changes  in  approach  or  strategy  are  identified,  affected  sections  of  the  project 
management  plan  may  need  to  be  updated  to  reflect  these  changes.  Elements  of  the  project  management  plan  that 
may  be  updated  include,  but  are  not  limited  to  the: 
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• Change  management  plan, 

• Communications  management  plan, 

• Cost  management  plan, 

• Human  resource  management  plan, 

• Procurement  management  plan, 

• Quality  management  plan, 

• Requirements  management  plan, 

• Risk  management  plan, 

• Schedule  management  plan, 

• Scope  management  plan,  and 

• Stakeholder  management  plan. 

13.4.3.4  Project  Documents  Updates 

Project  documents  that  may  be  updated  include,  but  are  not  limited  to: 

• Stakeholder  register.  This  is  updated  as  information  on  stakeholders  change,  when  new  stakeholders 
are  identified,  or  if  registered  stakeholders  are  no  longer  involved  in  or  impacted  by  the  project,  or  other 
updates  for  specific  stakeholders  are  required. 

• Issue  log.  This  is  updated  as  new  issues  are  identified  and  current  issues  are  resolved. 
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13.4.3.5  Organizational  Process  Assets  Updates 

The  organizational  process  assets,  which  may  be  updated  include,  but  are  not  limited  to: 

• Stakeholder  notifications.  Information  may  be  provided  to  stakeholders  about  resolved  issues,  approved 
changes,  and  general  project  status. 

• Project  reports.  Formal  and  informal  project  reports  describe  project  status  and  include  lessons  learned, 
issue  logs,  project  closure  reports,  and  outputs  from  other  Knowledge  Areas  (Sections  4-12). 

• Project  presentations.  Information  formally  or  informally  provided  by  the  project  team  to  any  or  all 
project  stakeholders. 

• Project  records.  Project  records  include  correspondence,  memos,  meeting  minutes,  and  other  documents 
describing  the  project. 

• Feedback  from  stakeholders.  Information  received  from  stakeholders  concerning  project  operations 
can  be  distributed  and  used  to  modify  or  improve  future  performance  of  the  project. 

• Lessons  learned  documentation.  Documentation  includes  the  root  cause  analysis  of  issues  faced, 
reasoning  behind  the  corrective  action  chosen,  and  other  types  of  lessons  learned  about  stakeholder 
management.  Lessons  learned  are  documented  and  distributed  so  that  they  become  part  of  the  historical 
database  for  both  the  project  and  the  performing  organization. 

13 
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ANNEX  A1 

THE  STANDARD  FOR  PROJECT  MANAGEMENT  OF  A PROJECT 


A project  is  a temporary  endeavor  undertaken  to  create  a unique  product,  service,  or  result.  The  temporary 
nature  of  projects  indicates  a definite  beginning  and  end.  The  end  is  reached  when  the  project’s  objectives  have 
been  achieved  or  when  the  project  is  terminated  because  its  objectives  will  not  or  cannot  be  met,  or  when  the  need 
for  the  project  no  longer  exists. 

Project  management  is  the  application  of  knowledge,  skills,  tools,  and  techniques  to  project  activities  to  meet 
project  requirements.  Project  management  is  accomplished  through  the  appropriate  application  and  integration  of 
logically  grouped  project  management  processes. 

Managing  a project  typically  includes: 

• Identifying  requirements; 

• Addressing  the  various  needs,  concerns,  and  expectations  of  the  stakeholders  as  the  project  is  planned 
and  carried  out; 

• Setting  and  maintaining  active  communication  with  stakeholders;  and 

• Balancing  the  competing  project  constraints,  which  include,  but  are  not  limited  to: 

o Scope, 
o Quality, 
o Schedule, 
o Budget, 
o Resources,  and 
o Risks. 

The  specific  project  circumstances  will  influence  the  constraints  on  which  the  project  manager  needs  to  focus 
and  require  effective  application  and  management  of  appropriate  project  management  processes. 
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A1 .1  What  is  a Standard? 

The  International  Organization  for  Standardization  (ISO)  and  others  define  a standard  as  a "Document  approved 
by  a recognized  body,  that  provides,  for  common  and  repeated  use,  rules,  guidelines,  or  characteristics  for  products, 
processes  or  services  with  which  compliance  are  not  mandatory.  ” (ISO  9453)  [1 1 ] 

In  October  1998,  PMI  was  accredited  as  a standards  developer  by  the  American  National  Standards  Institute 
(ANSI).  The  processes  outlined  in  this  Annex,  which  are  described  in  the  PMBOK®  Guide  - Fifth  Edition,  provide  the 
standard  for  project  management  of  a project. 


A1 .2  Framework  for  this  Standard 

This  standard  describes  the  nature  of  project  management  processes  in  terms  of  the  integration  between  the 
processes,  their  interactions,  and  the  purposes  they  serve.  For  this  standard,  it  is  assumed  that  the  project,  the 
project  manager  and  the  project  team  are  assigned  to  the  performing  organization.  Project  management  processes 
are  grouped  into  five  categories  known  as  Project  Management  Process  Groups  (or  Process  Groups): 

• Initiating  Process  Group.  Those  processes  performed  to  define  a new  project  or  a new  phase  of  an 
existing  project  by  obtaining  authorization  to  start  the  project  or  phase. 

• Planning  Process  Group.  Those  processes  required  to  establish  the  scope  of  the  project,  refine  the 
objectives,  and  define  the  course  of  action  required  to  attain  the  objectives  that  the  project  was  undertaken 
to  achieve. 

• Executing  Process  Group.  Those  processes  performed  to  complete  the  work  defined  in  the  project 
management  plan  to  satisfy  the  project  specifications. 

• Monitoring  and  Controlling  Process  Group.  Those  processes  required  to  track,  review,  and  regulate  the 
progress  and  performance  of  the  project;  identify  any  areas  in  which  changes  to  the  plan  are  required; 
and  initiate  the  corresponding  changes. 

• Closing  Process  Group.  Those  processes  performed  to  finalize  all  activities  across  all  Process  Groups  to 
formally  close  the  project  or  phase. 
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Project  Management  Process  Groups  are  linked  by  the  outputs  they  produce.  The  Process  Groups  are  seldom 
either  discrete  or  one-time  events;  they  are  overlapping  activities  that  occur  throughout  the  project.  The  output  of 
one  process  generally  becomes  an  input  to  another  process  or  is  a deliverable  of  the  project,  subproject,  or  project 
phase.  Deliverables  at  the  subproject  or  project  level  may  be  called  incremental  deliverables.  The  Planning  Process 
Group  provides  the  Executing  Process  Group  with  the  project  management  plan  and  project  documents,  and,  as 
the  project  progresses,  it  often  creates  updates  to  the  project  management  plan  and  the  project  documents.  Figure 
A1  -1  illustrates  how  the  Process  Groups  interact  and  shows  the  level  of  overlap  at  various  times.  If  the  project  is 
divided  into  phases,  the  Process  Groups  interact  within  each  phase. 


Level  of 
Process 
Interaction 


Start 


Closing 

Process 

Group 


Finish 


Figure  A1-1.  Process  Group  Interactions  in  a Project 


An  example  of  this  interaction  would  be  the  exit  of  a design  phase,  which  requires  sponsor  acceptance  of  the 
design  document.  Once  it  is  available,  the  design  document  provides  the  product  description  for  the  Planning  and 
Executing  Process  Groups  in  one  or  more  subsequent  phases.  When  a project  is  divided  into  phases,  the  Process 
Groups  are  carried  out,  as  appropriate,  to  effectively  drive  the  project  to  completion  in  a controlled  manner.  In 
multiphase  projects,  processes  are  repeated  within  each  phase  until  the  criteria  for  phase  completion  have  been 
satisfied. 
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A1 .3  Project  Management  Process  Groups 

The  following  sections  identify  and  describe  the  five  Project  Management  Process  Groups  required  for  any 
project.  These  five  Process  Groups  have  clear  dependencies  and  are  typically  performed  in  each  project  and 
highly  interact  with  one  another.  These  five  Process  Groups  are  independent  of  application  areas  or  industry  focus. 
Individual  Process  Groups  and  individual  processes  are  often  iterated  prior  to  completing  the  project  and  can  have 
interactions  within  a Process  Group  and  among  Process  Groups.  The  nature  of  these  interactions  varies  from  project 
to  project  and  may  or  may  not  be  performed  in  a particular  order. 

The  process  flow  diagram,  Figure  A1  -2,  provides  an  overall  summary  of  the  basic  flow  and  interactions  among 
Process  Groups  and  specific  stakeholders.  The  project  management  processes  are  linked  by  inputs  and  outputs 
where  the  result  or  outcome  of  one  process  becomes  the  input  to  another  process  but  not  necessarily  in  the  same 
Process  Group.  The  Process  Groups  are  not  project  phases.  In  fact,  it  is  possible  that  all  Process  Groups  could 
be  conducted  within  a phase.  As  projects  are  separated  into  distinct  phases  or  subcomponents,  such  as  concept 
development,  feasibility  study,  design,  prototype,  build,  or  test,  etc.,  all  of  the  Process  Groups  would  normally  be 
repeated  for  each  phase  or  subcomponent  along  the  lines  explained  above  and  illustrated  in  Figure  A1  -2. 
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» Project  statement  of  work 


» Procurement  documentation 


NOTE:  The  darker  dotted  lines  represent  relationships  between  Process  Groups;  the  lighter  dotted  lines  are  external  to  the  Process  Groups. 


Figure  A1-2.  Project  Management  Process  Interactions 
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Table  A1  -1  reflects  the  mapping  of  the  47  project  management  processes  into  the  5 Project  Management 
Process  Groups  and  the  1 0 Project  Management  Knowledge  Areas. 

The  project  management  processes  are  shown  in  the  Process  Group  in  which  most  of  the  activity  takes  place. 
For  example,  when  a process  that  normally  takes  place  in  the  Planning  Process  Group  is  updated  in  the  Executing 
Process  Group,  it  is  not  considered  a new  process. The  iterative  nature  of  project  management  means  that  processes 
from  any  group  may  be  used  throughout  the  project  life  cycle.  For  example,  executing  a risk  response  may  trigger 
the  Perform  Quantitative  Risk  Analysis  process  to  evaluate  the  impact. 
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Table  A1  -1 . Project  Management  Process  Group  and  Knowledge  Area  Mapping 
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A1 .4  Initiating  Process  Group 

The  Initiating  Process  Group  consists  of  those  processes  performed  to  define  a new  project  or  a new  phase 
of  an  existing  project  by  obtaining  authorization  to  start  the  project  or  phase.  Within  the  Initiating  processes,  the 
initial  scope  is  defined  and  initial  financial  resources  are  committed.  Internal  and  external  stakeholders  who  will 
interact  and  influence  the  overall  outcome  of  the  project  are  identified.  If  not  already  assigned,  the  project  manager 
will  be  selected.  This  information  is  captured  in  the  project  charter  and  stakeholder  register.  When  the  project 
charter  is  approved,  the  project  becomes  officially  authorized.  Although  the  project  management  team  may  help 
to  write  the  project  charter,  this  standard  assumes  that  business  case  assessment,  approval,  and  funding  are 
handled  external  to  the  project  boundaries  (Figure  A1-3).  A project  boundary  is  defined  as  the  point  in  time  that 
a project  or  project  phase  is  authorized  to  its  completion.  The  key  purpose  of  this  Process  Group  is  to  align  the 
stakeholders’  expectations  with  the  project’s  purpose,  give  them  visibility  about  the  scope  and  objectives,  and  show 
how  their  participation  in  the  project  and  it  associated  phases  can  ensure  that  their  expectations  are  achieved. 
These  processes  help  to  set  the  vision  of  the  project — what  is  needed  to  be  accomplished. 

Large  complex  projects  should  be  divided  into  separate  phases.  In  such  projects,  the  Initiating  processes 
are  carried  out  during  subsequent  phases  to  validate  the  decisions  made  during  the  original  Develop  Project 
Charter  and  Identify  Stakeholders  processes.  Performing  the  Initiating  processes  at  the  start  of  each  phase 
helps  to  keep  the  project  focused  on  the  business  need  that  the  project  was  undertaken  to  address.  The 
success  criteria  are  verified,  and  the  influence,  drivers,  and  objectives  of  the  project  stakeholders  are  reviewed. 
A decision  is  then  made  as  to  whether  the  project  should  be  continued,  delayed,  or  discontinued. 

Involving  the  sponsors,  customers,  and  other  stakeholders  during  initiation  creates  a shared  understanding  of 
success  criteria,  reduces  the  overhead  of  involvement,  and  generally  improves  deliverable  acceptance,  customer, 
and  other  stakeholder  satisfaction. 
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Figure  A1  -3.  Project  Boundaries 

Initiating  processes  may  be  performed  at  the  organizational,  program,  or  portfolio  level  and  would  then 
be  outside  of  the  project’s  level  of  control.  For  example,  prior  to  commencing  a project,  the  need  for  high- 
level  requirements  may  be  documented  as  part  of  a larger  organizational  initiative.  A process  of  evaluating 
alternatives  may  be  utilized  to  determine  the  feasibility  of  the  new  undertaking.  Clear  descriptions  of  the  project 
objectives  may  be  developed,  including  the  reasons  why  a specific  project  is  the  best  alternative  to  satisfy 
the  requirements.  The  documentation  for  this  decision  may  also  contain  the  initial  project  scope  statement, 
deliverables,  project  duration,  and  a forecast  of  the  resources  for  the  organization’s  investment  analysis.  As  part 
of  the  Initiating  processes,  the  project  manager  is  given  the  authority  to  apply  organizational  resources  to  the 
subsequent  project  activities. 
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The  dashed  circular  arrow  indicates  that  the  process  is  part  of  the 
Project  Integration  Management  Knowledge  Area.  This  Knowledge 
Area  coordinates  and  unifies  the  processes  from  the  other 
Knowledge  Areas. 


Figure  A1-4.  Initiating  Process  Group 
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A1 .4.1  Develop  Project  Charter 

Develop  Project  Charter  is  the  process  of  developing  a document  that  formally  authorizes  the  existence  of  a 
project  and  provides  the  project  manager  with  the  authority  to  apply  organizational  resources  to  project  activities. 
The  key  benefit  of  this  process  is  a well-defined  project  start  and  project  boundaries,  creation  of  a formal  record  of 
the  project,  and  a direct  way  for  senior  management  to  formally  accept  and  commit  to  the  project.  The  inputs  and 
outputs  for  this  process  are  shown  in  Figure  A1  -5. 
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Figure  A1-5.  Develop  Project  Charter:  Inputs  and  Outputs 

A1 .4.2  Identify  Stakeholders 

Identify  Stakeholders  is  the  process  of  identifying  the  people,  groups,  or  organizations  that  could  impact  or  be 
impacted  by  a decision,  activity,  or  outcome  of  the  project;  and  analyzing  and  documenting  relevant  information 
regarding  their  interests,  involvement,  interdependencies,  influence,  and  potential  impact  on  project  success.  The 
key  benefit  of  this  process  is  that  it  allows  the  project  manager  to  identify  the  appropriate  focus  for  each  stakeholder 
or  group  of  stakeholders.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -6. 


Inputs 


.1  Project  charter 
.2  Procurement  documents 
.3  Enterprise  environmental 
factors 

.4  Organizational  process 
assets 

V 


Outputs 


.1  Stakeholder  register 

V J 


J 


Figure  A1  -6.  Identify  Stakeholders:  Inputs  and  Outputs 
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A1.5  Planning  Process  Group 

The  Planning  Process  Group  consists  of  those  processes  performed  to  establish  the  total  scope  of  the 
effort,  define  and  refine  the  objectives,  and  develop  the  course  of  action  required  to  attain  those  objectives. 
The  Planning  processes  develop  the  project  management  plan  and  the  project  documents  that  will  be  used  to 
carry  out  the  project.  The  complex  nature  of  project  management  may  require  the  use  of  repeated  feedback 
loops  for  additional  analysis.  As  more  project  information  or  characteristics  are  gathered  and  understood, 
additional  planning  will  likely  be  required.  Significant  changes  occurring  throughout  the  project  life  cycle 
trigger  a need  to  revisit  one  or  more  of  the  planning  processes  and,  possibly,  some  of  the  initiating  processes. 
This  progressive  detailing  of  the  project  management  plan  is  called  progressive  elaboration,  indicating  that 
planning  and  documentation  are  iterative  and  ongoing  activities.  The  key  benefit  of  this  Process  Group  is  to 
delineate  the  strategy  and  tactics  as  well  as  the  course  of  action  or  a path  to  successfully  complete  the  project 
or  phase.  When  the  Planning  Process  Group  is  well  managed,  it  is  much  easier  to  get  stakeholder  buy-in  and 
engagement.  These  processes  describe  how  this  will  be  done,  resulting  in  the  desired  objectives. 

The  project  management  plan  and  project  documents  developed  as  outputs  from  the  Planning  Process  Group 
will  explore  all  aspects  of  the  scope,  time,  costs,  quality,  communications,  human  resources,  risks,  procurements, 
and  stakeholder  management. 

Updates  arising  from  approved  changes  during  the  project  (generally  during  Monitoring  and  Controlling 
processes  and  specifically  during  Direct  and  Manage  Project  Work  process)  may  significantly  impact  parts  of  the 
project  management  plan  and  the  project  documents.  Updates  to  these  documents  provide  greater  precision  with 
respect  to  schedule,  costs,  and  resource  requirements  to  meet  the  defined  project  scope. 

The  project  team  seeks  input  and  encourages  involvement  from  all  stakeholders  when  planning  the  project 
and  developing  the  project  management  plan  and  project  documents.  Since  the  feedback  and  refinement  process 
cannot  continue  indefinitely,  procedures  set  by  the  organization  dictate  when  the  initial  planning  effort  ends.  These 
procedures  will  be  affected  by  the  nature  of  the  project,  the  established  project  boundaries,  appropriate  monitoring 
and  controlling  activities,  as  well  as  the  environment  in  which  the  project  will  be  performed. 

Other  interactions  among  the  processes  within  the  Planning  Process  Group  are  dependent  upon  the  nature  of 
the  project.  For  example,  for  some  projects  there  will  be  little  or  no  identifiable  risks  until  after  significant  planning 
has  been  done.  At  that  time,  the  team  might  recognize  that  the  cost  and  schedule  targets  are  overly  aggressive, 
thus  involving  considerably  more  risk  than  previously  understood.  The  results  of  the  iterations  are  documented  as 
updates  to  the  project  management  plan  or  to  various  project  documents. 
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The  Planning  Process  Group  (Figure  A1-7)  includes  the  project  management  processes  identified  in  Figures 
A1  -8  through  AT  -31  (see  Sections  A1 .5.1  through  A1. 5.24). 
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The  dashed  circular  arrow  indicates  that  the  process  is  part  of  the  Project 
Integration  Management  Knowledge  Area.  This  Knowledge  Area  coordinates 
and  unifies  the  processes  from  the  other  Knowledge  Areas. 


Figure  A1-7.  Planning  Process  Group 
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A1.5.1  Develop  Project  Management  Plan 

Develop  Project  Management  Plan  is  the  process  of  defining,  preparing,  and  coordinating  all  subsidiary  plans  and 
integrating  them  into  a comprehensive  project  management  plan.  The  key  benefit  of  this  process  is  a central  document 
that  defines  the  basis  of  all  project  work.  The  inputs  and  outputs  for  this  process  are  depicted  in  Figure  A1  -8. 
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Figure  A1-8.  Develop  Project  Management  Plan:  Inputs  and  Outputs 


A1.5.2  Plan  Scope  Management 

Plan  Scope  Management  is  the  process  of  creating  a scope  management  plan  that  documents  how  the  project 
scope  will  be  defined,  validated,  and  controlled.  The  key  benefit  of  this  process  is  that  it  provides  guidance  and 
direction  on  how  scope  will  be  managed  throughout  the  project.  The  inputs  and  outputs  of  this  process  are  depicted 
in  Figure  A1  -9. 
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Figure  A1-9.  Plan  Scope  Management:  Inputs  and  Outputs 
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A1 .5.3  Collect  Requirements 

Collect  Requirements  is  the  process  of  determining,  documenting,  and  managing  stakeholder  needs  and 
requirements  to  meet  project  objectives.  The  key  benefit  of  this  process  is  that  it  provides  the  basis  for  defining 
and  managing  the  project  scope  including  product  scope.  The  inputs  and  outputs  of  this  process  are  depicted  in 
Figure  A1-10. 
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Figure  A1-10.  Collect  Requirements:  Inputs  and  Outputs 


A1.5.4  Define  Scope 

Define  Scope  is  the  process  of  developing  a detailed  description  of  the  project  and  product.  The  key  benefit  of 
this  process  is  that  it  describes  the  project,  service,  or  result  boundaries  by  defining  which  of  the  requirements 
collected  will  be  included  in  and  excluded  from  the  project  scope.  The  inputs  and  outputs  of  this  process  are 
depicted  in  Figure  A1 -11. 
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Figure  A1  -11.  Define  Scope:  Inputs  and  Outputs 
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A1.5.5  Create  WBS 

Create  WBS  is  the  process  of  subdividing  project  deliverables  and  project  work  into  smaller,  more  manageable 
components.  The  key  benefit  of  this  process  is  that  it  provides  a structured  vision  of  what  has  to  be  delivered.  The 
inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -1 2. 
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Figure  A1-12.  Create  WBS:  Inputs  and  Outputs 

A1.5.6  Plan  Schedule  Management 

Plan  Schedule  Management  is  the  process  of  establishing  the  policies,  procedures,  and  documentation  for 
planning,  developing,  managing,  executing,  and  controlling  the  project  schedule.  The  key  benefit  of  this  process  is 
that  it  provides  guidance  and  direction  on  how  the  project  schedule  will  be  managed  throughout  the  project.  The 
inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -1 3. 


Inputs 


.1  Project  management  plan 
.2  Project  charter 
.3  Enterprise  environmental 
factors 

.4  Organizational  process 
assets 

V J 


Outputs 


.1  Schedule  management 
plan 

V J 


Figure  A1-13.  Plan  Schedule  Management:  Inputs  and  Outputs 
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A1 .5.7  Define  Activities 

Define  Activities  is  the  process  of  identifying  and  documenting  the  specific  actions  to  be  performed  to  produce 
the  project  deliverables.  The  key  benefit  of  this  process  is  to  break  down  work  packages  into  activities  that  provide 
a basis  for  estimating,  scheduling,  executing,  monitoring,  and  controlling  the  project  work.  The  inputs  and  outputs 
of  this  process  are  depicted  in  Figure  A1  -1 4. 
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Figure  A1-14.  Define  Activities:  Inputs  and  Outputs 


A1 .5.8  Sequence  Activities 

Sequence  Activities  is  the  process  of  identifying  and  documenting  relationships  among  the  project  activities.  The 
key  benefit  of  this  process  is  that  it  defines  the  logical  sequence  of  work  to  obtain  the  greatest  efficiency  given  all 
project  constraints.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1 -15. 
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Figure  A1-15.  Sequence  Activities:  Inputs  and  Outputs 
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A1 .5.9  Estimate  Activity  Resources 

Estimate  Activity  Resources  is  the  process  of  estimating  the  type  and  quantities  of  material,  human  resources, 
equipment,  or  supplies  required  to  perform  each  activity.  The  key  benefit  of  this  process  is  that  it  identifies  the  type, 
quantity,  and  characteristics  of  resources  required  to  complete  the  activity  which  allows  more  accurate  cost  and 
duration  estimates.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -1 6. 
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Figure  A1-16.  Estimate  Activity  Resources:  Inputs  and  Outputs 


A1.5.10  Estimate  Activity  Durations 

Estimate  Activity  Durations  is  the  process  of  estimating  the  number  of  work  periods  needed  to  complete 
individual  activities  with  estimated  resources.  The  key  benefit  of  this  process  is  that  it  provides  the  amount  of 
time  each  activity  will  take  to  complete,  which  is  a major  input  into  the  Develop  Schedule  process.  The  inputs  and 
outputs  of  this  process  are  depicted  in  Figure  A1  -1 7. 
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Figure  A1-17.  Estimate  Activity  Durations:  Inputs  and  Outputs 


A1.5.11  Develop  Schedule 

Develop  Schedule  is  the  process  of  analyzing  activity  sequences,  durations,  resource  requirements,  and 
schedule  constraints  to  create  the  project  schedule  model.  The  key  benefit  of  this  process  is  that  by  entering 
schedule  activities,  durations,  resources,  resource  availabilities,  and  logical  relationships  into  the  scheduling  tool, 
it  generates  a schedule  model  with  planned  dates  for  completing  project  activities.  The  inputs  and  outputs  of  this 
process  are  depicted  in  Figure  AT -1 8. 


434  ©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKB  Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


ANNEX  A1  - THE  STANDARD  FOR  PROJECT  MANAGEMENT  OF  A PROJECT 


.1  Schedule  management 


.1  Schedule  baseline 
.2  Project  schedule 
.3  Schedule  data 


plan 

.2  Activity  list 

.3  Activity  attributes 

.4  Project  schedule  network 


.4  Project  calendars 


.5  Project  management  plan 


diagrams 

.5  Activity  resource 


.6  Project  documents 


updates 


requirements 

.6  Resource  calendars  V. 


updates 


.7  Activity  duration 
estimates 

.8  Project  scope  statement 
.9  Risk  register 
.10  Project  staff  assignments 
.11  Resource  breakdown 
structure 

.12  Enterprise  environmental 
factors 

.13  Organizational  process 
assets 


Figure  A1-18.  Develop  Schedule:  Inputs  and  Outputs 


A1.5.12  Plan  Cost  Management 

Plan  Cost  Management  is  the  process  that  establishes  the  policies,  procedures,  and  documentation  for  planning, 
managing,  expending,  and  controlling  project  costs.  The  key  benefit  of  this  process  is  that  it  provides  guidance  and 
direction  on  how  the  project  costs  will  be  managed  throughout  the  project.  The  inputs  and  outputs  of  this  process 
are  depicted  in  Figure  A1 -19. 
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Inputs 


.1  Project  management  plan 
.2  Project  charter 
.3  Enterprise  environmental 
factors 

.4  Organizational  process 
assets 

V 


Outputs 


.1  Cost  management  plan 

V J 


J 


Figure  A1-19.  Plan  Cost  Management:  Inputs  and  Outputs 


A1.5.13  Estimate  Costs 

Estimate  Costs  is  the  process  of  developing  an  approximation  of  the  monetary  resources  needed  to  complete 
project  activities.  The  key  benefit  of  this  process  is  that  it  determines  the  amount  of  cost  required  to  complete 
project  work.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -20. 


Inputs 


.1  Cost  management  plan 
.2  Human  resource 
management  plan 
.3  Scope  baseline 
.4  Project  schedule 
.5  Risk  register 
.6  Enterprise  environmental 
factors 

.7  Organizational  process 
assets 

V J 


Outputs 


.1  Activity  cost  estimates 
.2  Basis  of  estimates 
.3  Project  documents 
updates 

V / 


Figure  A1-20.  Estimate  Costs:  Inputs  and  Outputs 
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A1.5.14  Determine  Budget 

Determine  Budget  is  the  process  of  aggregating  the  estimated  costs  of  individual  activities  or  work  packages  to 
establish  an  authorized  cost  baseline.  The  key  benefit  of  this  process  is  that  it  determines  the  cost  baseline  against 
which  project  performance  can  be  monitored  and  controlled.  The  inputs  and  outputs  of  this  process  are  depicted 
in  Figure  A1  -21. 


Inputs 


.1  Cost  management  plan 
.2  Scope  baseline 
.3  Activity  cost  estimates 
.4  Basis  of  estimates 
.5  Project  schedule 
.6  Resource  calendars 
.7  Risk  register 
.8  Agreements 
.9  Organizational  process 
assets 

V J 


Outputs 


.1  Cost  baseline 
.2  Projectfunding 
requirements 
.3  Project  documents 
updates 

V J 


Figure  A1  -21.  Determine  Budget:  Inputs  and  Outputs 


A1.5.15  Plan  Quality  Management 

Plan  Quality  Management  is  the  process  of  identifying  quality  requirements  and/or  standards  for  the  project  and 
its  deliverables,  and  documenting  how  the  project  will  demonstrate  compliance  with  relevant  quality  requirements. 
The  key  benefit  of  this  process  is  that  it  provides  guidance  and  direction  on  how  quality  will  be  managed  and 
validated  throughout  the  project.  The  input  and  outputs  of  this  process  are  depicted  in  Figure  A1  -22. 
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Inputs 


.1  Project  management  plan 
.2  Stakeholder  register 
.3  Risk  register 
.4  Requirements 
documentation 
.5  Enterprise  environmental 
factors 

.6  Organizational  process 
assets 

V J 


Outputs 


.1  Quality  management  plan 
.2  Process  improvement  plan 
.3  Quality  metrics 
.4  Quality  checklists 
.5  Project  documents 
updates 

V J 


Figure  A1-22.  Plan  Quality  Management:  Inputs  and  Outputs 


A1.5.16  Plan  Human  Resource  Management 

Plan  Human  Resource  Management  is  the  process  of  identifying  and  documenting  project  roles,  responsibilities, 
required  skills,  reporting  relationships,  and  creating  a staffing  management  plan.  The  key  benefit  of  this  process 
is  that  it  establishes  project  roles  and  responsibilities,  project  organization  charts,  and  the  staffing  management 
plan  including  the  timetable  for  staff  acquisition  and  release.  The  input  and  outputs  of  this  process  are  depicted  in 
Figure  A1-23. 


Inputs 


.1  Project  management  plan 

.2  Activity  resource 
requirements 

.3  Enterprise  environmental 
factors 

.4  Organizational  process 
assets 


r outputs 

1 

.1  Human  resource 

management  plan 

V 

J 

J 


Figure  A1-23.  Plan  Human  Resource  Management:  Inputs  and  Outputs 
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A1.5.17  Plan  Communications  Management 

Plan  Communications  Management  is  the  process  of  developing  an  appropriate  approach  and  plan  for  project 
communications  based  on  stakeholder’s  information  needs  and  requirements,  and  available  organizational  assets. 
The  key  benefit  of  this  process  is  that  it  identifies  and  documents  the  approach  to  communicate  most  effectively 
and  efficiently  with  stakeholders.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -24. 


Inputs 


Outputs 


.1  Project  management  plan 
.2  Stakeholder  register 
.3  Enterprise  environmental 
factors 

.4  Organizational  process 
assets 

V J 


.1  Communications 
management  plan 
.2  Project  documents 
updates 

V 


y 


Figure  A1-24.  Plan  Communications  Management:  Inputs  and  Outputs 


A1.5.18  Plan  Risk  Management 

Plan  Risk  Management  is  the  process  of  defining  how  to  conduct  risk  management  activities  for  a project. 
The  key  benefit  of  this  process  is  that  it  ensures  that  the  degree,  type,  and  visibility  of  risk  management  are 
commensurate  with  both  the  risks  and  the  importance  of  the  project  to  the  organization.  The  input  and  outputs  of 
this  process  are  depicted  in  Figure  A1  -25. 


Inputs 


.1  Project  management  plan 
.2  Project  charter 
.3  Stakeholder  register 
.4  Enterprise  environmental 
factors 

.5  Organizational  process 
assets 

V 


Outputs 


.1  Risk  management  plan 

V J 


J 


Figure  A1-25.  Plan  Risk  Management:  Inputs  and  Outputs 
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A1.5.19  Identify  Risks 

Identify  Risks  is  the  process  of  determining  which  risks  may  affect  the  project  and  documenting  their 
characteristics.  The  key  benefit  of  this  process  is  the  documentation  of  existing  risks  and  the  knowledge  and 
ability  it  provides  to  the  project  team  to  anticipate  events.  The  inputs  and  outputs  of  this  process  are  depicted  in 
Figure  A1-26. 


Inputs 


.1  Risk  management  plan 
.2  Cost  management  plan 
.3  Schedule  management 
plan 

.4  Quality  management  plan 
.5  Human  resource 
management  plan 
.6  Scope  baseline 
.7  Activity  cost  estimates 


.8  Activity  duration 
estimates 

.9  Stakeholder  register 
.10  Project  documents 
.11  Procurement  documents 
.12  Enterprise  environmental 
factors 

.13  Organizational  process 
assets 

V J 

Figure  A1-26.  Identify  Risks:  Inputs  and  Outputs 


A1 .5.20  Perform  Qualitative  Risk  Analysis 

Perform  Qualitative  Risk  Analysis  is  the  process  of  prioritizing  risks  for  further  analysis  or  action  by  assessing 
and  combining  their  probability  of  occurrence  and  impact.  The  key  benefit  of  this  process  is  that  it  enables  project 
managers  to  reduce  the  level  of  uncertainty  and  to  focus  on  high-priority  risks.  The  inputs  and  outputs  of  this 
process  are  depicted  in  Figure  A1 -27. 
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Inputs 


.1  Risk  management  plan 
.2  Scope  baseline 
.3  Risk  register 
.4  Enterprise  environmental 
factors 

.5  Organizational  process 
assets 

V 


r outputs 

.1  Project  documents 

updates 

V 

J 

J 


Figure  A1-27.  Perform  Qualitative  Risk  Analysis:  Inputs  and  Outputs 


A1 .5.21  Perform  Quantitative  Risk  Analysis 

Perform  Quantitative  Risk  Analysis  is  the  process  of  numerically  analyzing  the  effect  of  identified  risks  on  overall 
project  objectives.  The  key  benefit  of  this  process  is  that  it  produces  quantitative  risk  information  to  support  decision 
making  in  order  to  reduce  project  uncertainty.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -28. 


Inputs 


.1  Risk  management  plan 
.2  Cost  management  plan 
.3  Schedule  management 


plan 

.4  Risk  register 
.5  Enterprise  environmental 
factors 

.6  Organizational  process 
assets 

V J 

Figure  A1-28.  Perform  Quantitative  Risk  Analysis:  Inputs  and  Outputs 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK®  Guide)  - Fifth  Edition 


441 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


ANNEX  A1  - THE  STANDARD  FOR  PROJECT  MANAGEMENT  OF  A PROJECT 


A1.5.22  Plan  Risk  Responses 

Plan  Risk  Responses  is  the  process  of  developing  options  and  actions  to  enhance  opportunities  and  to  reduce 
threats  to  project  objectives.  The  key  benefit  of  this  process  is  that  it  addresses  the  risks  by  their  priority,  inserting 
resources  and  activities  into  the  budget,  schedule  and  project  management  plan  as  needed.  The  inputs  and  outputs 
of  this  process  are  depicted  in  Figure  A1  -29. 


Inputs 


.1  Risk  management  plan 
.2  Risk  register 


Outputs 


Project  management  plan 
updates 

Project  documents 
updates 


Figure  A1-29.  Plan  Risk  Responses:  Inputs  and  Outputs 

A1.5.23  Plan  Procurement  Management 

Plan  Procurement  Management  is  the  process  of  documenting  project  procurement  decisions,  specifying  the 
approach,  and  identifying  potential  sellers.  The  key  benefit  of  this  process  is  that  it  determines  whether  to  acquire 
outside  support,  and  if  so,  what  to  acquire,  how  to  acquire  it,  how  much  is  needed,  and  when  to  acquire  it.  The 
inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -30. 
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Inputs 


.1  Project  management  plan 
.2  Requirements 
documentation 
.3  Risk  register 
.4  Activity  resource 
requirements 
.5  Project  schedule 
.6  Activity  cost  estimates 
.7  Stakeholder  register 
.8  Enterprise  environmental 
factors 

.9  Organizational  process 
assets 

v / 


Outputs 


.1  Procurement  management 
plan 

.2  Procurement  statement 
of  work 

.3  Procurement  documents 
.4  Source  selection  criteria 
.5  Make-or-buy  decisions 
.6  Change  requests 
.7  Project  documents 
updates 

V J 


Figure  A1-30.  Plan  Procurement  Management:  Inputs  and  Outputs 


A1.5.24  Plan  Stakeholder  Management 

Plan  Stakeholder  Management  is  the  process  of  developing  appropriate  management  strategies  to  effectively 
engage  stakeholders  throughout  the  project  life  cycle,  based  on  the  analysis  of  their  needs,  interests,  and  potential 
impact  on  project  success.  The  key  benefit  of  this  process  is  that  it  provides  a clear,  actionable  plan  to  interact 
with  project  stakeholders  to  support  the  project’s  interests.  The  inputs  and  outputs  of  this  process  are  depicted  in 
Figure  A1-31. 


r ^ 

Inputs 

.1  Project  management  plan 
.2  Stakeholder  register 

.1 

.3  Enterprise  environmental 
factors 

.2 

.4  Organizational  process 
assets 

V J 


Outputs 


Stakeholder  management 
plan 

Project  documents 
updates 

y 


Figure  A1  -31.  Plan  Stakeholder  Management:  Inputs  and  Outputs 
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A1 .6  Executing  Process  Group 

The  Executing  Process  Group  consists  of  those  processes  performed  to  complete  the  work  defined  in  the 
project  management  plan  to  satisfy  the  project  specifications.  This  Process  Group  involves  coordinating  people  and 
resources,  managing  stakeholder  expectations,  as  well  as  integrating  and  performing  the  activities  of  the  project  in 
accordance  with  the  project  management  plan  (Figure  A1  -32). 

During  project  execution,  results  may  require  planning  updates  and  rebaselining.  This  can  include  changes 
to  expected  activity  durations,  changes  in  resource  productivity  and  availability,  and  unanticipated  risks.  Such 
variances  may  affect  the  project  management  plan  or  project  documents  and  may  require  detailed  analysis 
and  development  of  appropriate  project  management  responses.  The  results  of  the  analysis  can  trigger  change 
requests  that,  if  approved,  may  modify  the  project  management  plan  or  other  project  documents  and  possibly 
require  establishing  new  baselines.  A large  portion  of  the  project’s  budget  will  be  expended  in  performing 
the  Executing  Process  Group  processes.  The  Executing  Process  Group  (Figure  A1-32)  includes  the  project 
management  processes  identified  in  Figures  A1  -33  through  A1  -40  (see  Sections  A1 .6.1  through  A1 .6.8). 
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Project  Human 
Resource  Management 


Project  Stakeholder 
Management 


13.3 

Manage 

Stakeholder 
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Project  Quality 
Management 

8.2 

Perform  Quality 
Assurance 
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Project  Integration 
Management 


Vl 


4.3 

Direct  and 
Manage 
Project 
Work 


Project  Procurement 
Management 

12.2 
Conduct 
Procurements 


\ 


Project  Communications 
Management 


10.2 
Manage 
Communications 


The  dashed  circular  arrow  indicates  that  the  process  is  part  of  the  Project  Integration  Management  Knowledge 
Area.  This  Knowledge  Area  coordinates  and  unifies  the  processes  from  the  other  Knowledge  Areas. 


Figure  A1-32.  Executing  Process  Group 


A1.6.1  Direct  and  Manage  Project  Work 

Direct  and  Manage  Project  Work  is  the  process  of  leading  and  performing  the  work  defined  in  the  project 
management  plan  and  implementing  approved  changes  to  achieve  the  project’s  objectives.  The  key  benefit  of  this 
process  is  that  it  provides  overall  management  of  the  project  work.  The  inputs  and  outputs  of  this  process  are 
depicted  in  Figure  A1 -33. 
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Inputs  ■ Outputs 


.1  Project  management  plan 

.2  Approved  change 
requests 

.3  Enterprise  environmental 
factors 

.4  Organizational  process 
assets 

V 


.1  Deliverables 
.2  Work  performance  data 
.3  Change  requests 
.4  Project  management  plan 
updates 

.5  Project  documents 
updates 


Figure  A1-33.  Direct  and  Manage  Project  Work:  Inputs  and  Outputs 


A1.6.2  Perform  Quality  Assurance 

Perform  Quality  Assurance  is  the  process  of  auditing  the  quality  requirements  and  the  results  from  quality 
control  measurements  to  ensure  that  appropriate  quality  standards  and  operational  definitions  are  used.  The  key 
benefit  of  this  process  is  it  facilitates  the  improvement  of  quality  processes.  The  input  and  outputs  of  this  process 
are  depicted  in  Figure  A1  -34. 


Inputs 


.1  Quality  management  plan 
.2  Process  improvement  plan 
.3  Quality  metrics 
.4  Quality  control 
measurements 
.5  Project  documents 

V J 


Outputs 


.1  Change  requests 

.2  Project  management  plan 
updates 

.3  Project  documents 
updates 

.4  Organizational  process 
assets  updates 

V J 


Figure  A1-34.  Perform  Quality  Assurance:  Inputs  and  Outputs 
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A1 .6.3  Acquire  Project  Team 

Acquire  Project  Team  is  the  process  of  confirming  human  resource  availability  and  obtaining  the  team  necessary 
to  complete  project  activities.  The  key  benefit  of  this  process  consists  of  outlining  and  guiding  the  team  selection 
and  responsibility  assignment  to  obtain  a successful  team.  The  inputs  and  outputs  of  this  process  are  depicted  in 
Figure  A1-35. 


Inputs 


.1  Human  resource 
management  plan 
.2  Enterprise  environmental 
factors 

.3  Organizational  process 
assets 

V J 


Outputs 


.1  Project  staff  assignments 
.2  Resource  calendars 
.3  Project  management  plan 
updates 

V ) 


Figure  A1-35.  Acquire  Project  Team:  Inputs  and  Outputs 


A1 .6.4  Develop  Project  Team 

Develop  Project  Team  is  the  process  of  improving  competencies,  team  member  interaction,  and  overall  team 
environment  to  enhance  project  performance.  The  key  benefit  of  this  process  is  that  it  results  in  improved  teamwork, 
enhanced  people  skills  and  competencies,  motivated  employees,  reduced  staff  turnover  rates,  and  improved  overall 
project  performance.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -36. 


Inputs 


.1  Human  resource 
management  plan 
.2  Project  staff  assignments 
.3  Resource  calendars 

V J 


Outputs 


.1  Team  performance 
assessments 

.2  Enterprise  environmental 
factors  updates 


Figure  A1-36.  Develop  Project  Team:  Inputs  and  Outputs 
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A1 .6.5  Manage  Project  Team 

Manage  Project  Team  is  the  process  of  tracking  team  member  performance,  providing  feedback,  resolving 
issues,  and  managing  team  changes  to  optimize  project  performance.  The  key  benefit  of  this  process  is  that  it 
influences  team  behavior,  manages  conflict,  resolves  issues,  and  appraises  team  member  performance.  The  inputs 
and  outputs  of  this  process  are  depicted  in  Figure  A1  -37. 


Inputs 


.1  Human  resource 
management  plan 
.2  Project  staff  assignments 
.3  Team  performance 
assessments 
.4  Issue  log 

.5  Work  performance  reports 
.6  Organizational  process 
assets 

V J 

Figure  A1-37.  Manage 


Outputs 


.1  Change  requests 
.2  Project  management  plan 
updates 

.3  Project  documents 
updates 

.4  Enterprise  environmental 
factors  updates 
.5  Organizational  process 
assets  updates 

V J 

Project  Team:  Inputs  and  Outputs 


A1.6.6  Manage  Communications 

Manage  Communications  is  the  process  of  creating,  collecting,  distributing,  storing,  retrieving,  and  the  ultimate 
disposition  of  project  information  in  accordance  with  the  communications  management  plan.  The  key  benefit  of  this 
process  is  that  it  enables  an  efficient  and  effective  communications  flow  between  project  stakeholders.  The  inputs 
and  outputs  of  this  process  are  depicted  in  Figure  A1  -38. 


Inputs 


.1  Communications 
management  plan 
.2  Work  performance  reports 
.3  Enterprise  environmental 
factors 

.4  Organizational  process 
assets 

V J 


Outputs 


.1  Project  communications 

.2  Project  management  plan 
updates 

.3  Project  documents 
updates 

.4  Organizational  process 
assets  updates 

V J 


Figure  A1  -38.  Manage  Communications:  Inputs  and  Outputs 
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A1 .6.7  Conduct  Procurements 

Conduct  Procurements  is  the  process  of  obtaining  seller  responses,  selecting  a seller,  and  awarding  a contract. 
The  key  benefit  of  this  process  is  that  it  provides  alignment  of  internal  and  external  stakeholder  expectations 
through  established  agreements.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -39. 


Inputs 


.1  Procurement  management 
plan 

.2  Procurement  documents 
.3  Source  selection  criteria 
.4  Seller  proposals 
.5  Project  documents 
.6  Make-or-buy  decisions 
.7  Procurement  statement  of 
work 

.8  Organizational  process 
assets 

V J 


Outputs 


.1  Selected  sellers 
.2  Agreements 
.3  Resource  calendar 
.4  Change  requests 
.5  Project  management  plan 
updates 

.6  Project  documents 
updates 

v J 


Figure  A1-39.  Conduct  Procurements:  Inputs  and  Outputs 


A1.6.8  Manage  Stakeholder  Engagement 

Manage  Stakeholder  Engagement  is  the  process  of  communicating  and  working  with  stakeholders  to  meet 
their  needs/expectations,  address  issues  as  they  occur,  and  foster  appropriate  stakeholder  engagement  in  project 
activities  throughout  the  project  life  cycle.  The  key  benefit  of  this  process  is  that  it  allows  the  project  manager 
to  increase  support  and  minimize  resistance  from  stakeholders,  significantly  increasing  the  chances  to  achieve 
project  success.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -40. 
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.1  Stakeholder  management 


.1  Issue  log 

.2  Change  requests 

.3  Project  management  plan 


plan 

.2  Communications 


management  plan 
.3  Change  log 
.4  Organizational  process 


updates 

.4  Project  documents 


updates 

.5  Organizational  process 


assets 


assets  updates 


Figure  A1-40.  Manage  Stakeholder  Engagement:  Inputs  and  Outputs 


A1 .7  Monitoring  and  Controlling  Process  Group 

The  Monitoring  and  Controlling  Process  Group  consists  of  those  processes  required  to  track,  review,  and 
orchestrate  the  progress  and  performance  of  the  project;  identify  any  areas  in  which  changes  to  the  plan  are 
required;  and  initiate  the  corresponding  changes.  The  key  benefit  of  this  Process  Group  is  that  project  performance 
is  measured  and  analyzed  at  regular  intervals,  appropriate  events  or  exception  conditions  to  identify  variances  from 
the  project  management  plan.  The  Monitoring  and  Controlling  Process  Group  also  involves: 

• Controlling  changes  and  recommending  corrective  or  preventive  action  in  anticipation  of  possible 
problems, 

• Monitoring  the  ongoing  project  activities  against  the  project  management  plan  and  the  project  performance 
measurement  baseline,  and 

• Influencing  the  factors  that  could  circumvent  integrated  change  control  or  configuration  management  so 
only  approved  changes  are  implemented. 
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This  continuous  monitoring  provides  the  project  team  insight  into  the  health  of  the  project  and  identifies 
any  areas  requiring  additional  attention.  The  Monitoring  and  Controlling  Process  Group  not  only  monitors  and 
controls  the  work  being  done  within  a Process  Group,  but  also  monitors  and  controls  the  entire  project  effort. 
In  multiphase  projects,  the  Monitoring  and  Controlling  Process  Group  coordinates  project  phases  in  order  to 
implement  corrective  or  preventive  actions  to  bring  the  project  into  compliance  with  the  project  management 
plan.  This  review  can  result  in  recommended  and  approved  updates  to  the  project  management  plan.  For 
example,  a missed  activity  finish  date  may  require  adjustments  and  trade-offs  between  budget  and  schedule 
objectives.  In  order  to  reduce  control  overheads,  management  by  exception  procedures  and  other  techniques 
can  be  appropriately  considered.  The  Monitoring  and  Controlling  Process  Group  (Figure  A1-41)  includes  the 
following  project  management  processes  (Sections  A1 .7.1  through  A1 .7.1 1 ): 
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Management 


Project  Time 
Management 
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Control 
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Management 
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Management 
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12.3 

Control 
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Control 

Costs 


Project  Quality 
Management 


8.3 

Control 

Quality 


Project  Communications 
Management 


Project  Risk 
Management 


11.6 

Control  Risks 


10.35 

Control 

Communications 


The  dashed  circular  arrow  indicates  that  the  process  is  part  of  the  Project  Integration  Management  Knowledge 
Area.  This  Knowledge  Area  coordinates  and  unifies  the  processes  from  the  other  Knowledge  Areas. 


Figure  A1-41.  Monitoring  and  Controlling  Process  Group 
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A1.7.1  Monitor  and  Control  Project  Work 

Monitor  and  Control  Project  Work  is  the  process  of  tracking,  reviewing,  and  reporting  the  progress  to  meet  the 
performance  objectives  defined  in  the  project  management  plan.  The  key  benefit  of  this  process  is  that  it  allows 
stakeholders  to  understand  the  current  state  of  the  project;  the  steps  taken;  and  budget,  schedule,  and  scope 
forecasts.  The  inputs  and  outputs  for  this  process  are  depicted  in  Figure  A1  -42. 


Inputs 


.1  Project  management  plan 
.2  Schedule  forecasts 
.3  Cost  forecasts 
.4  Validated  changes 
.5  Work  performance 
information 

.6  Enterprise  environmental 
factors 

.7  Organizational  process 
assets 

V / 


Outputs 


.1  Change  requests 
.2  Work  performance  reports 
.3  Project  management  plan 
updates 

.4  Project  documents 
updates 

V J 


Figure  A1-42.  Monitor  and  Control  Project  Work:  Inputs  and  Outputs 


A1 .7.2  Perform  Integrated  Change  Control 

Perform  Integrated  Change  Control  is  the  process  of  reviewing  all  change  requests;  approving  changes 
and  managing  changes  to  deliverables,  organizational  process  assets,  project  documents,  and  the  project 
management  plan;  and  communicating  their  disposition.  It  reviews  all  requests  for  changes  or  modifications  to 
project  documents,  deliverables,  baselines  orthe  project  management  plan,  and  approves  or  rejects  the  changes. 
The  key  benefit  of  this  process  is  that  it  allows  for  documented  changes  within  the  project  to  be  considered  in 
an  integrated  fashion  while  reducing  project  risk,  which  often  arises  from  changes  made  without  consideration 
to  the  overall  project  objectives  or  plans.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -43. 
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Inputs 


.1  Project  management  plan 
.2  Work  performance  reports 
.3  Change  requests 
.4  Enterprise  environmental 
factors 

.5  Organizational  process 
assets 

V J 


Outputs 


.1  Approved  change 
requests 

.2  Change  log 

.3  Project  management  plan 
updates 

.4  Project  documents 
updates 

V J 


Figure  A1-43.  Perform  Integrated  Change  Control:  Inputs  and  Outputs 


A1 .7.3  Validate  Scope 

Validate  Scope  is  the  process  of  formalizing  acceptance  of  the  completed  project  deliverables.  The  key  benefit 
of  this  process  is  that  it  brings  objectivity  to  the  acceptance  process  and  increases  the  chance  of  final  product, 
service,  or  result  acceptance  by  validating  each  deliverable.  The  inputs  and  outputs  of  this  process  are  depicted  in 
Figure  A1-44. 


Inputs 


.1  Project  management  plan 
.2  Requirements 
documentation 
.3  Requirements  traceability 
matrix 

.4  Verified  deliverables 
.5  Work  performance  data 

V J 


Outputs 


.1  Accepted  deliverables 
.2  Change  requests 
.3  Work  performance 
information 
.4  Project  documents 
updates 

V y 


Figure  A1-44.  Validate  Scope:  Inputs  and  Outputs 
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A1 .7.4  Control  Scope 

Control  Scope  is  the  process  of  monitoring  the  status  of  the  project  and  product  scope  and  managing  changes  to 
the  scope  baseline.  The  key  benefit  of  this  process  is  that  it  allows  the  scope  baseline  to  be  maintained  throughout 
the  project.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -45. 


Inputs 


.1  Project  management  plan 
.2  Requirements 
documentation 
.3  Requirements  traceability 
matrix 

.4  Work  performance  data 
.5  Organizational  process 
assets 

V / 


Outputs 


.1  Work  performance 
information 
.2  Change  requests 
.3  Project  management  plan 
updates 

.4  Project  documents 
updates 

.5  Organizational  process 
assets  updates 

V J 


Figure  A1-45.  Control  Scope:  Inputs  and  Outputs 


A1.7.5  Control  Schedule 

Control  Schedule  is  the  process  of  monitoring  the  status  of  project  activities  to  update  project  progress  and 
manage  changes  to  the  schedule  baseline  to  achieve  the  plan.  The  key  benefit  of  this  process  is  that  it  provides  the 
means  to  recognize  deviation  from  the  plan  and  take  corrective  and  preventive  actions  and  thus  minimize  risk.  The 
inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -46. 
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Inputs 


.1  Project  management  plan 
.2  Project  schedule 
.3  Work  performance  data 
.4  Project  calendars 
.5  Schedule  data 
.6  Organizational  process 
assets 

V / 


Outputs 


.1  Work  performance 
information 
.2  Schedule  forecasts 
.3  Change  requests 
.4  Project  management  plan 
updates 

.5  Project  documents 
updates 

.6  Organizational  process 
assets  updates 

V _ J 


Figure  A1  -46.  Control  Schedule:  Inputs  and  Outputs 


A1 .7.6  Control  Costs 

Control  Costs  is  the  process  of  monitoring  the  status  of  the  project  to  update  the  project  costs  and  managing 
changes  to  the  cost  baseline.  The  key  benefit  of  this  process  is  that  it  provides  the  means  to  recognize  variance 
from  the  plan  in  order  to  take  corrective  action  and  minimize  risk.  The  inputs  and  outputs  of  this  process  are 
depicted  in  Figure  A1 -47. 


Inputs  ■ Outputs 


.1  Project  management  plan 
.2  Project  funding 
requirements 

.3  Work  performance  data 
.4  Organizational  process 
assets 


.1  Work  performance 
information 
.2  Cost  forecasts 
.3  Change  requests 
.4  Project  management  plan 
updates 

.5  Project  documents 
updates 

.6  Organizational  process 
assets  updates 


Figure  A1-47.  Control  Costs:  Inputs  and  Outputs 
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A1 .7.7  Control  Quality 

Control  Quality  is  the  process  of  monitoring  and  recording  results  of  executing  the  quality  activities  to  assess 
performance  and  recommend  necessary  changes.  The  key  benefits  of  this  process  include:  (1)  identifying  the 
causes  of  poor  process  or  product  quality  and  recommending  and/or  taking  action  to  eliminate  them;  and  (2) 
validating  that  project  deliverables  and  work  meet  the  requirements  specified  by  key  stakeholders  necessary  for 
final  acceptance.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -48. 
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.1  Project  management  plan 
.2  Quality  metrics 
.3  Quality  checklists 
.4  Work  performance  data 
.5  Approved  change 
requests 
.6  Deliverables 
.7  Project  documents 
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V J 
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.3  Verified  deliverables 
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.5  Change  requests 
.6  Project  management  plan 
updates 

.7  Project  documents 
updates 

.8  Organizational  process 
assets  updates 

V J 


Figure  A1  -48.  Control  Quality:  Inputs  and  Outputs 


A1.7.8  Control  Communications 

Control  Communications  is  the  process  of  monitoring  and  controlling  communications  throughout  the  entire 
project  life  cycle  to  ensure  the  information  needs  of  the  project  stakeholders  are  met.  The  key  benefit  of  this  process 
is  that  it  ensures  an  optimal  information  flow  among  all  communication  participants  at  any  moment  in  time.  The 
inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -49. 
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Inputs  ■ Outputs 


.1  Project  management  plan 
.2  Project  communications 
.3  Issue  log 

.4  Work  performance  data 
.5  Organizational  process 
assets 


.1  Work  performance 
information 
.2  Change  requests 
.3  Project  management  plan 
updates 

.4  Project  documents 
updates 

.5  Organizational  process 
assets  updates 


Figure  A1-49.  Control  Communications:  Inputs  and  Outputs 


A1 .7.9  Control  Risks 

Control  Risks  is  the  process  of  implementing  risk  response  plans,  tracking  identified  risks,  monitoring  residual 
risks,  identifying  new  risks,  and  evaluating  risk  process  effectiveness  throughout  the  project.  The  key  benefit  of  this 
process  is  that  it  improves  efficiency  of  the  risk  approach  throughout  the  project  life  cycle  to  continuously  optimize 
risk  responses.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -50. 
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Figure  A1-50.  Control  Risks:  Inputs  and  Outputs 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK®  Guide)  - Fifth  Edition 


457 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


ANNEX  A1  - THE  STANDARD  FOR  PROJECT  MANAGEMENT  OF  A PROJECT 


A1.7.10  Control  Procurements 

Control  Procurements  is  the  process  of  managing  procurement  relationships,  monitoring  contract  performance, 
and  making  changes  and  corrections  to  contracts  as  appropriate.  The  key  benefit  of  this  process  is  that  it  ensures 
that  both  the  seller’s  and  buyer’s  performance  meets  procurement  requirements  according  to  the  terms  of  the  legal 
agreement.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -51 . 
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Figure  A1  -51.  Control  Procurements:  Inputs  and  Outputs 


A1.7.11  Control  Stakeholder  Engagement 

Control  Stakeholder  Engagement  is  the  process  of  monitoring  overall  project  stakeholder  relationships  and 
adjusting  strategies  and  plans  for  engaging  stakeholders.  The  key  benefit  of  this  process  is  that  it  will  maintain 
or  increase  the  efficiency  and  effectiveness  of  stakeholder  engagement  activities  as  the  project  evolves  and  its 
environment  changes.  The  inputs  and  outputs  of  this  process  are  depicted  in  Figure  A1  -52. 


458  ©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKB  Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


ANNEX  A1  - THE  STANDARD  FOR  PROJECT  MANAGEMENT  OF  A PROJECT 


.1  Project  management  plan 
.2  Issue  log 

.3  Work  performance  data 
.4  Project  documents 


.1  Work  performance 


information 
.2  Change  requests 
.3  Project  management  plan 


J updates 


.4  Project  documents 
updates 


.5  Organizational  process 
assets  updates 


Figure  A1-52.  Control  Stakeholder  Engagement:  Inputs  and  Outputs 


A1 .8  Closing  Process  Group 

The  Closing  Process  Group  consists  of  those  processes  performed  to  conclude  all  activities  across  all  Project 
Management  Process  Groups  to  formally  complete  the  project,  phase,  or  contractual  obligations.  This  Process 
Group,  when  completed,  verifies  that  the  defined  processes  are  completed  within  all  the  Process  Groups  to  close 
the  project  or  a project  phase,  as  appropriate,  and  formally  establishes  that  the  project  or  project  phase  is  complete. 

This  Process  Group  also  formally  establishes  the  premature  closure  of  the  project.  Prematurely  closed  projects 
may  include,  for  example:  aborted  projects,  cancelled  projects,  and  projects  in  a critical  situation.  In  specific  cases, 
when  some  contracts  cannot  be  formally  closed  (e.g.  claims,  ending  clauses  etc.)  or  some  activities  are  to  be 
transferred  to  other  organizational  units,  specific  hand-over  procedures  may  be  arranged  and  finalized. 

At  project  or  phase  closure,  the  following  may  occur: 

• Obtain  acceptance  by  the  customer  or  sponsor  to  formally  close  the  project  or  phase, 

• Conduct  post-project  or  phase-end  review, 

• Record  impacts  of  tailoring  to  any  process, 

• Document  lessons  learned, 
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• Apply  appropriate  updates  to  organizational  process  assets, 

• Archive  all  relevant  project  documents  in  the  project  management  information  system  (PMIS)  to  be  used 
as  historical  data, 

• Close  out  all  procurements  activities  ensuring  termination  of  all  relevant  agreements,  and 

• Perform  team  members’  assessment  and  release  project  resources. 

The  Closing  Process  Group  (Figure  A1-53)  includes  the  following  project  management  processes  (See 
Sections  A1 .8.1  and  A1 .8.2): 


Project  Integration 
Management 
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Close  Project 
or  Phase 


Project  Procurement 
Management 


12.4 

Close 

Procurements 


♦ 


The  dashed  circular  arrow  indicates  that  the  process  is  part  of  the 
Project  Integration  Management  Knowledge  Area.  This  Knowledge 
Area  coordinates  and  unifies  the  processes  from  the  other 
Knowledge  Areas. 


Figure  A1-53.  Closing  Process  Group 


A1 .8.1  Close  Project  or  Phase 

Close  Project  or  Phase  is  the  process  of  finalizing  all  activities  across  all  of  the  Project  Management  Process 
Groups  to  formally  complete  the  project  or  phase.  The  key  benefit  of  this  process  is  that  it  provides  lessons  learned, 
the  formal  ending  of  project  work,  and  the  release  of  organization  resources  to  pursue  new  endeavors.  The  inputs 
and  outputs  of  this  process  are  depicted  in  Figure  A1  -54. 
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r ^ 

Inputs 

Outputs 

.1  Project  management  plan 
.2  Accepted  deliverables 
.3  Organizational  process 
assets 

^ J 

.1  Final  product,  service,  or 
result  transition 
.2  Organizational  process 
assets  updates 

^ 

Figure  A1-54.  Close  Project  or  Phase:  Inputs  and  Outputs 

A1.8.2  Close  Procurements 

Close  Procurements  is  the  process  of  completing  each  procurement.  The  key  benefit  of  this  process  is  that  it 
documents  agreements  and  related  documentation  for  future  reference.  The  inputs  and  outputs  of  this  process  are 
depicted  in  Figure  AT -55. 


Inputs 


.1  Project  management  plan 
.2  Procurement  documents 


Outputs 


.1  Closed  procurements 
.2  Organizational  process 
assets  updates 


Figure  A1-55.  Close  Procurements:  Inputs  and  Outputs 
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APPENDIX  XI 

FIFTH  EDITION  CHANGES 


The  purpose  of  this  appendix  is  to  give  a detailed  explanation  of  the  changes  made  to  A Guide  to  the  Project 
Management  Body  of  Knowledge  (PMBOK®  Guide) — Fourth  Edition  to  create  the  PMBOK®  Guide — Fifth  Edition. 


XI  .1  Scope  of  Update 

The  approved  scope  for  the  PMBOK ® Guide  - Fifth  Edition  explicitly  states: 

• Comments  and  feedback,  both  deferred  during  the  development  of  the  PMBOK®  Guide  - Fourth  Edition 
and  received  by  PMI  since  its  development,  will  be  reviewed  and  determined  whether  material  will  be 
included  or  excluded  in  the  new  edition. 

• Review  all  text  and  graphics  in  the  document  to  make  sure  the  information  is  accurate,  clear,  complete 
and  relevant,  revising  as  necessary. 

• Review,  interpret,  and  ensure  appropriate  alignment  with  ISO  21 500  [1 2]  in  the  development  of  the  standard. 

• Ensure  harmonization  with  any  other  relevant  PMI  standards. 

• Consider  project  management  role  delineation  study  results,  as  appropriate. 

• Reposition  Section  3 (The  Standard  for  Project  Management)  as  a stand-alone,  ANSI-approved  standard 
included  within  the  Fifth  Edition  as  an  Appendix  or  attachment. 

• Standard  is  written  for  project  management  practitioners  and  other  stakeholders  of  the  project 
management  profession. 

• Standard  describes  the  principles  and  processes  that  shape  the  practices  that  are  unique  to  projects. 

• Standard  ensures  that  any  terminology  contained  within  the  PMI  Lexicon  is  represented  consistently  and 
identically  in  the  standard. 

With  that  directive  in  mind,  the  update  team  adopted  an  approach  aimed  at  achieving  a greater  degree  of 
consistency  and  clarity  by  refining  the  processes,  standardizing  inputs  and  outputs  where  possible,  and  implementing 
a global  approach  for  documenting  the  inputs  and  outputs. 
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Along  with  a focus  on  consistency  and  clarity,  the  update  team  worked  to  complete  the  requirements  for 
factoring  feedback  received  for  the  PMBOK®  Guide- Fourth  Edition,  and  ensure  alignment  and  harmonization  with 
relevant  PMI  standards,  ISO  21500,  PMI  Lexicon  of  Project  Management  Terms,  and  the  PMI  role  delineation  study 
for  project  managers. 


XI  .2  Rules  for  Handling  Inputs,  Tools  and  Techniques,  and  Outputs  (ITTOs) 

Business  rules  were  established  to  further  aid  consistency  in  handling  the  order  and  detail  of  information  within 
the  ITTOs  for  each  project  management  process.  These  rules  are: 

• ITTO  Fundamental  Rules: 

o Inputs  are  any  documents  that  are  key  to  the  process. 

o Process  outputs  should  map  as  an  input  to  another  project  management  process  unless  the 
output  is  a terminal  output  or  embedded  within  another  input  such  as  process  documents. 

o Process  inputs  should  map  as  an  output  from  another  project  management  process  unless  the 
input  comes  from  outside  the  project. 

• Project  Documents  Rules: 

o On  the  ITTO  input  list,  if  the  input  is  a major  project  document,  it  needs  to  be  specifically  listed 
out. 

o On  the  ITTO  output  list,  specific  project  documents  are  put  on  the  list  the  first  time  they  are 
created  as  an  output.  Subsequently,  these  are  listed  as  “project  document  updates”  on  the  ITTO 
output  list,  and  described  in  the  section  narrative. 

• Project  Management  Plan  Rules: 

o On  the  ITTO  input  list,  if  the  subsidiary  plans  and  baselines  from  the  project  management  plan 
serve  as  major  process  inputs,  then  these  need  to  be  specifically  listed  out. 

o On  the  ITTO  output  list,  subsidiary  plans  and  baselines  for  the  project  management  plan  are 
grouped  as  a single  output  as  “project  management  plan  updates”  and  described  in  the  section 
narrative. 

o On  the  ITTO  input  list,  for  those  planning  processes  that  create  a subsidiary  plan,  the  project 
management  plan  is  listed  as  the  key  input. 

o For  control  processes,  the  key  input  is  “project  management  plan,”  rather  than  specific  subsidiary 
plans.  And  the  output  is  “project  management  plan  updates”  rather  than  an  update  to  a specific 
subsidiary  plan. 
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• EEF/OPA  Referencing  Rule  for  Process  Inputs: 

o When  referencing  EEFs  or  OPAs,  include  the  phrase  “Described  in  Section”  and  state  2.1 .4  for 
OPAs  or  2.1 .5  for  EEFs. 

• Other  Consistency  Rules: 

o Rename  “project  document  update”  and  “organizational  process  asset  updates”  to  “project 
documents  updates”  and  “organizational  process  assets  updates.” 

o For  consistency  across  the  PMBOK®  Guide,  document  titles  are  not  to  be  capitalized  in  the  text. 

• Sequencing  Rules: 

o For  inputs  and  outputs:  plans,  subsidiary  plans,  and  baselines  are  listed  first, 
o Project  management  plan  first,  then  subsidiary  plans,  then  baselines, 
o When  plans  are  a major  output,  they  are  always  listed  first. 

o For  inputs  work  performance  data/information/reports,  these  are  listed  immediately  before  the 
enterprise  environmental  factors. 

o Enterprise  environmental  factors  and  organizational  process  assets  are  listed  last  in  that  order. 

o Tools  and  techniques  have  meetings  listed  last. 

o When  updates  are  an  output  they  are  listed  in  the  following  sequence: 
o Project  management  plan/subsidiary  plan  updates, 
o Project  documents  updates, 
o Enterprise  environmental  factors  updates,  and 
o Organizational  process  assets  updates. 

XI  .3  Established  Rules  for  Ensuring  Harmonization  Between  Glossary  Terms 
and  the  PMI  Lexicon  of  Project  Management  Terms 

To  ensure  that  terms  used  in  the  PMBOK ® Guide  align  with  the  PMI  Lexicon  of  Project  Management  Terms  and 
harmonize  with  other  PMI  standards,  business  rules  were  established  and  adhered  to  in  the  Fifth  Edition  update. 
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• For  terms  found  in  both  the  PMBOK®  Guide  anti  the  PMI  Lexicon,  the  definition  from  the  PMi  LexicontaY.ee 
precedence. 

• Where  terms  used  in  the  PMBOK ® Guide  are  not  found  in  the  PMI  Lexicon  but  are  found  in  other  relevant 
PMI  standards  (e.g.,  The  Standard  for  Program  Management,  Organizational  Project  Management 
Maturity  Model  (0PM3®),  The  Standard  for  Portfolio  Management,  Practice  Standard  for  Earned  Value 
Management,  Practice  Standard  for  Scheduling,  etc.),  the  definition  of  the  terms  shall  be  the  same.  If  the 
definitions  do  not  align  with  the  respective  standards,  the  term  is  elevated  to  the  PMI  Lexicon  team  for 
assistance  in  creating  an  acceptable  common  definition. 


XI  .4  Project  Management  Plan  and  Its  Subsidiary  Plans 

To  improve  consistency  and  aid  clarity  around  the  various  subsidiary  plans  that  make  up  the  overall  project 
management  plan,  the  team  added  four  planning  processes:  Plan  Scope  Management,  Plan  Schedule  Management, 
Plan  Cost  Management,  and  Plan  Stakeholder  Management.  These  changes  bring  back  the  scope  planning  process 
from  the  Third  Edition  and  add  three  new  planning  processes.  The  additions  provide  clearer  guidance  for  the 
concept  that  each  major  Knowledge  Area  has  a need  for  the  project  team  to  actively  think  through  and  plan  how 
aspects  from  the  related  processes  are  planned  and  managed.  It  also  reinforces  the  concept  that  each  of  the 
subsidiary  plans  are  integrated  through  the  overall  project  management  plan,  which  becomes  the  major  planning 
document  for  guiding  further  project  planning  and  execution. 

This  change  also  ensures  harmonization  with  other  PMI  standards.  For  example,  a detailed  planning  process 
for  Plan  Schedule  Management  reinforces  the  need  for  detailed  planning  to  address  project  scheduling  issues 
such  as  selecting  the  scheduling  method  and  tool  during  early  planning  stages  as  part  of  the  overall  Project  Time 
Management  processes.  This  concept  of  detailed  planning  for  project  scheduling  related  decisions  aligns  with  the 
Practice  Standard  for  Scheduling  anti  ensures  harmonization  across  PMI  standards. 


XI  .5  Consistency  in  Handling  Project  Management  Work  Execution  Data  and 
Information  Flow 

To  improve  consistency  and  add  clarity  regarding  project  data  and  information  flows  during  project  work 
execution,  the  team  redefined  work  performance  data,  work  performance  information,  and  work  performance 
reports  to  align  with  the  DIKW  (Data,  Information,  Knowledge,  Wisdom)  model  used  in  the  field  of  Knowledge 
Management. 


466  ©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMB0KB  Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


APPENDIX  XI  - FIFTH  EDITION  CHANGES 


• Work  Performance  Data.  The  raw  observations  and  measurements  identified  during  activities  performed 
to  carry  out  the  project  work.  Examples  include  reported  percent  of  work  physically  completed,  quality 
technical  performance  measures,  start  and  finish  dates  of  schedule  activities,  number  of  change  requests, 
number  of  defects,  actual  costs,  actual  durations,  etc. 

• Work  Performance  Information.  The  performance  data  collected  from  various  controlling  processes, 
analyzed  in  context  and  integrated  based  on  relationships  across  areas.  Examples  of  performance 
information  are  status  of  deliverables,  implementation  status  for  change  requests,  forecasted  estimates 
to  complete. 

• Work  Performance  Reports.  The  physical  or  electronic  representation  of  work  performance  information 
compiled  in  project  documents,  intended  to  generate  decisions,  raise  issues,  actions,  or  awareness. 
Examples  include  status  reports,  memos,  justifications,  information  notes,  electronic  dashboards, 
recommendations,  and  updates. 

The  redefined  data  model  was  then  applied  consistently  to  the  inputs  and  outputs  for  the  various  controlling  and 
executing  processes  as  illustrated  in  Figure  XI -1. 


Figure  XI -1.  Refined  Data  Model 
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XI  .6  Section  1 — Introduction 

Sections  1 .2,  1 .4,  and  1 .6  were  realigned  and  harmonized  with  first  sections  in  The  Standard  for  Program 
Management  - Third  Edition  and  The  Standard  for  Portfolio  Management  - Third  Edition.  This  ensures  the 
information  regarding  the  relationship  between  projects,  programs,  and  portfolios  is  treated  consistently  across 
all  three  standards.  Additional  text  was  added  to  Section  1.4.4  to  expand  the  discussion  on  project  management 
offices.  Section  1 .5  on  Project  Management  and  Operations  Management  was  expanded  to  more  broadly  address 
the  relationship  among  project  management,  operations  management,  and  organizational  strategy.  A new  section 
was  added  to  address  the  importance  of  interpersonal  skills  of  a project  manager  and  refers  the  reader  to  Appendix 
X3  of  the  PMBOK®  Guide  for  further  discussion  on  the  importance  of  interpersonal  skills  in  managing  projects. 
Section  1 .8  on  Enterprise  Environmental  Factors  was  moved  to  Section  2. 


XI  .7  Section  2 — Project  Life  Cycle  and  Organization 

The  content  of  Section  2 was  reorganized  to  improve  content  flow  and  understanding.  The  section  on 
organizational  influence  on  project  management  was  moved  to  the  beginning  of  the  section  and  expanded  to 
provide  broader  coverage  of  how  organizational  factors  can  influence  the  conduct  of  project  teams.  The  discussion 
of  enterprise  environmental  factors  was  moved  into  this  section  from  Section  1 . The  section  on  stakeholders  was 
expanded  to  better  address  project  stakeholders  and  their  impact  on  project  governance.  A new  section  was  added 
to  address  the  characteristics  and  structure  of  the  project  team.  The  section  on  project  life  cycle  was  moved  to  the 
end  of  the  section  and  expanded  to  further  explain  life  cycles  and  phases. 


XI  .8  Section  3 Project  Management  Processes  for  a Project 

Section  3 of  the  PMBOK ® Guide  - Fourth  Edition  was  moved  into  a new  Annex  in  the  PMBOK®  Guide  - Fifth 
Edition  (Annex  A1  - The  Standard  for  Project  Management  of  a Project).  The  introduction  to  this  section  was 
cleaned  up  and  expanded  to  enable  this  annex  to  serve  as  a stand-alone  document.  This  positions  the  Standard  for 
Project  Management  away  from  the  main  body  of  the  PMBOK®  Guide  material  allowing  the  evolution  of  the  Body  of 
Knowledge  material  to  be  separate  from  the  actual  Standard  for  Project  Management. 
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XI  .9  New  Section  3 for  PMBOK®  Guide  - Fifth  Edition 

A replacement  Section  3 was  developed  for  the  Guide  - Fifth  edition.  This  new  section  bridges  the 

content  between  Sections  1 and  2 and  the  Knowledge  Area  sections.  The  new  section  introduces  the  project 
management  processes  and  Process  Groups  as  in  the  previous  editions  of  the  PMBOK®  Guide.  However,  it  does  not 
list  each  of  the  processes  associated  with  each  of  the  Project  Management  Process  Groups. 


XI  .10  Split  Section  10  on  Project  Communications  Management  into  Two 
Separate  Sections 

Deferred  and  post-publication  comments  on  the  Project  Communications  Knowledge  Area  of  the  PMBOK®  Guide 
- Fourth  Edition  uncovered  a need  to  modify  this  Knowledge  Area  as  well  as  the  processes  within  the  Knowledge 
Area.  In  general,  the  comments  fell  into  three  groups: 

• Eliminate  confusion  created  between  the  processes  of  Distribute  Information  and  Report  Performance 
and  their  overlap  with  processes  for  Control  Scope,  Control  Schedule,  and  Control  Cost. 

• Tighten  the  focus  of  Project  Communications  Management  to  planning  for  the  communications  needs 
of  the  project,  collecting,  storing,  and  disseminating  project  information,  and  monitoring  overall  project 
communications  to  ensure  its  efficiency. 

• Break  out  and  expand  on  stakeholder  management  concepts  to  reflect  not  solely  upon  (a)  analyzing 
stakeholder  expectations  and  its  impact  on  the  project,  and  (b)  developing  appropriate  management 
strategies  for  effectively  engaging  stakeholders  in  project  decisions  and  execution,  but  also  upon 
continuous  dialogue  with  stakeholders  to  meet  their  needs  and  expectations,  address  issues  as  they 
occur,  and  foster  appropriate  stakeholder  engagement  in  project  decisions  and  activities. 

Planning  for  and  managing  the  communication  needs  of  the  project  as  well  as  the  stakeholders’  needs  are 
two  distinct  keys  to  project  success.  The  concept  being  reinforced  is  that  both  are  discrete  Knowledge  Areas 
in  which  stakeholder  management  is  not  simply  better  management  of  communications  nor  which  improved 
communications  is  simply  better  stakeholder  management.  This  concept  drives  the  need  to  treat  these  two  critical 
keys  for  project  success  as  distinct  areas. 

Revamping  this  Knowledge  Area  by  separating  Project  Stakeholders  Management  from  Project  Communications 
Management  provides  the  following  benefits: 
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• Focuses  on  not  only  managing  the  expectations  of  the  various  stakeholder  groups  but  actively  working  to 
ensure  an  appropriate  level  of  engagement  of  project  stakeholders  in  the  decision  making  and  activities 
of  the  project. 

• Aligns  with  the  growing  body  of  research  showing  stakeholder  engagement  as  one  of  the  keys  to  overall 
project  success. 

• Improves  the  alignment  between  the  PMBOK®  Guide  and  The  Standard  for  Program  Management. 

• Aligns  better  with  the  focus  on  stakeholder  management  being  put  forward  with  the  new  ISO  21500 
standard. 

• Allows  better  emphasis  on  Project  Communications  Management  by  focusing  on  the  main  purpose  of 
communication  activities  to  collect,  store,  organize,  and  distribute  project  information. 

• Enables  the  realignment  of  project  communications  processes,  thus  addressing  the  confusion  and  overlap 
surrounding  project  performance  analysis  and  reporting. 

Section  1 0 was  separated  into  two  distinct  Knowledge  Areas:  Project  Communications  Management  and  Project 
Stakeholder  Management.  This  change  takes  the  communication  processes  currently  contained  in  Section  10 
and  refocuses  them  to  project  communications  planning,  executing,  and  controlling.  The  two  current  stakeholder 
aligned  processes  within  Section  1 0 (Identify  Stakeholders  and  Manage  Stakeholder  Expectations)  were  moved  into 
a new  section  addressing  stakeholder  management.  Stakeholder-related  text  from  Section  2.3  was  also  moved  into 
this  new  section.  The  project  management  processes  related  to  managing  project  stakeholders  were  expanded  to 
include: 

• Identify  Stakeholders, 

• Develop  Stakeholder  Management  Plan, 

• Manage  Stakeholder  Engagement,  and 

• Control  Stakeholder  Engagement. 
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XI  .11  Process  Changes 

As  part  of  the  process,  changes  several  process  names  were  changed  to  improve  consistency  across  the 
processes  and  to  improve  clarity.  All  processes  that  create  a subsidiary  plan  were  named  using  the  form  of  Plan 
{XXX}  Management.  The  Monitor  and  Controlling  processes  were  named  using  the  form  Control  {XXX},  since  the 
act  of  controlling  a process  includes  monitoring  the  process.  These  changes  improved  the  consistency  of  how 
processes  are  named  across  all  processes.  In  addition  to  process  name  changes,  several  other  processes  were 
added  or  modified  as  described  elsewhere  in  this  appendix.  The  list  below  summarizes  the  process  changes. 

• 4.3  Direct  and  Manage  Project  Execution — changed  to  Direct  and  Manage  Project  Work 

• 5.1  Plan  Scope  Management — added 

• 5.5  Verify  Scope — changed  to  Validate  Scope 

• 6.1  Plan  Schedule  Management — added 

• 7.1  Plan  Cost  Management — added 

• 8.1  Plan  Quality — changed  to  Plan  Quality  Management 

• 8.3  Perform  Quality  Control — changed  to  Control  Quality 

• 9.1  Develop  Human  Resource  Plan — changed  to  Plan  Human  Resource  Management 

• 1 0.2  Plan  Communications — changed  to  Section  1 0.1  Plan  Communications  Management 

• 1 0.3  Distribute  Information — changed  to  Section  1 0.2  Manage  Communications 

• 1 0.5  Report  Performance — changed  to  Section  1 0.3  Control  Communications 

• 11.6  Monitor  and  Control  Risks — changed  to  Control  Risks 

• 12.1  Plan  Procurements — changed  to  Plan  Procurement  Management 

• 1 2.3  Administer  Procurements — changed  to  Control  Procurements 

• 1 0.1  Identify  Stakeholders — moved  to  Section  1 3.1  Identify  Stakeholders 

• 1 3.2  Plan  Stakeholder  Management — added 

• 1 0.4  Manage  Stakeholder  Expectations — changed  to  Section  1 3.3  Manage  Stakeholders  Engagement 

• 1 3.4  Control  Stakeholders  Engagement — added 
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XI  .12  Section  4 — Project  Integration  Management  Changes 

Process  definitions  were  revised  for  Develop  Project  Charter,  Develop  Project  Management  Plan,  Direct  and 
Manage  Project  Work,  Monitor  and  Control  Project  Work,  and  Perform  Integrated  Change  Control  to  better  align 
with  the  PMI  Lexicon  and  improve  clarity  of  the  definitions.  The  Direct  and  Manage  Project  Execution  was 
renamed  to  Direct  and  Manage  Project  Work  to  better  align  with  its  definition  and  reinforce  that  this  process 
applies  beyond  the  Executing  processes.  Other  changes  consist  primarily  of  expanded  explanations,  refinements 
to  tools  and  techniques  for  several  processes,  and  refinements  to  the  inputs  and  outputs  for  several  processes  to 
better  tie  the  integration  processes  to  other  project  management  processes.  A table  was  added  to  the  discussion 
of  the  output  for  of  the  Develop  Project  Management  Plan  process  to  bring  clarity  to  the  differentiation  between 
project  documents  and  Inputs  and  outputs  were  adjusted  for  several  processes  to  reflect  the  new  model  of 
project  data  and  information  flow  during  the  execution  of  project  work. 

The  following  table  summarizes  the  Section  4 processes: 


Table  XI -1.  Section  4 Changes 


Fourth  Edition  Sections 

Fifth  Edition  Sections 

4.1  Develop  Project  Charter 

4.1  Develop  Project  Charter 

4.2  Develop  Project  Management  Plan 

4.2  Develop  Project  Management  Plan 

4.3  Direct  and  Manage  Project  Execution 

4.3  Direct  and  Manage  Project  Work 

4.4  Monitor  and  Control  Project  Work 

4.4  Monitor  and  Control  Project  Work 

4.5  Perform  Integrated  Change  Control 

4.5  Perform  Integrated  Change  Control 

4.6  Close  Project  or  Phase 

4.6  Close  Project  or  Phase 

472  ©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKB  Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


APPENDIX  XI  - FIFTH  EDITION  CHANGES 


XI  .13  Section  5 — Project  Scope  Management  Changes 

In  Section  5.1 , the  concept  of  a Develop  Scope  Management  Plan  process  was  brought  back  as  a way  to 
ensure  consistency  across  all  project  planning  processes  and  to  reinforce  that  subsidiary  plans  are  developed  to 
plan  the  details  for  each  major  Knowledge  Area.  To  support  consistency  in  naming,  the  processes  that  create  the 
subsidiary  plans,  the  Develop  Scope  Management  Plan  was  named  Plan  Scope  Management.  The  discussion  within 
the  Collect  Requirements  process  was  expanded  to  make  clear  this  process  focuses  on  collecting  all  requirements 
necessary  for  project  success.  These  requirements  include  the  requirements  for  the  product,  service,  or  result  to  be 
delivered  by  the  project,  any  quality  requirements  the  project  must  meet,  and  any  other  project  management  related 
requirements  deemed  critical  for  project  success.  The  Verify  Scope  process  was  renamed  to  Validate  Scope  and 
the  text  was  reworked  to  add  emphasis  that  this  process  is  not  solely  about  accepting  deliverables  but  validating 
that  the  deliverables  will  deliver  value  to  the  business  and  confirms  that  the  deliverables,  as  provided,  will  fulfill 
the  project  objectives,  as  well  as  their  intended  use  to  the  project  stakeholders.  Inputs  and  outputs  were  adjusted 
for  several  processes  to  reflect  the  new  model  of  project  data  and  information  flow  during  the  execution  of  project 
work. 

The  following  table  summarizes  the  Section  5 processes: 


Table  XI -2.  Section  5 Changes 


Fourth  Edition  Sections 

Fifth  Edition  Sections 

5.1  Plan  Scope  Management 

5.1  Collect  Requirements 

5.2  Collect  Requirements 

5.2  Define  Scope 

5.3  Define  Scope 

5.3  Create  WBS 

5.4  Create  WBS 

5.4  Verify  Scope 

5.5  Validate  Scope 

5.5  Control  Scope 

5.6  Control  Scope 
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XI  .14  Section  6 — Project  Time  Management  Changes 

Section  6 reflects  changes  within  the  industry  and  detailed  in  the  Practice  Standard  for  Scheduling  - 
Second  Edition. 

As  part  of  reinforcing  the  concept  of  detailed  subsidiary  plans  being  created  for  each  major  Knowledge  Area 
and  then  aggregated  into  the  overall  project  management  plan,  a new  process  was  added  for  Plan  Schedule 
Management.  This  process  adds  focus  on  the  preliminary  decisions  around  developing  and  maintaining  the 
project’s  schedule  model.  Process  definitions  were  revised  for  Define  Activities,  Estimate  Activity  Resources, 
Estimate  Activity  Durations,  and  Control  Schedule  to  improve  clarity  of  the  definitions.  Several  processes  were 
modified  with  new  inputs  and/or  updated  outputs.  Agile  concepts  were  incorporated  into  the  Develop  Schedule 
process.  Figures  and  associated  text  were  updated  to  clarify  scheduling  concepts  addressed  in  the  section. 
Added  emphasis  was  placed  on  resource  optimization  techniques  used  in  project  scheduling.  Some  inputs  and 
outputs  were  renamed  for  several  processes  to  support  consistency  between  the  various  project  management 
processes.  Inputs  and  outputs  were  adjusted  for  several  processes  to  reflect  the  new  model  of  project  data  and 
information  flow  during  the  execution  of  project  work. 

The  following  table  summarizes  the  Section  6 processes: 


Table  XI -3.  Section  6 Changes 


Fourth  Edition  Sections 

Fifth  Edition  Sections 

6.1  Plan  Schedule  Management 

6.1  Define  Activities 

6.2  Define  Activities 

6.2  Sequence  Activities 

6.3  Sequence  Activities 

6.3  Estimate  Activity  Resources 

6.4  Estimate  Activity  Resources 

6.4  Estimate  Activity  Durations 

6.5  Estimate  Activity  Durations 

6.5  Develop  Schedule 

6.6  Develop  Schedule 

6.6  Control  Schedule 

6.7  Control  Schedule 
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XI  .15  Section  7 — Project  Cost  Management  Changes 

Section  7 reflects  changes  coming  from  within  the  industry  and  detailed  in  the  Practice  Standard  for  Estimating 
and  the  Practice  Standard  for  Earned  Value  Management- Second  Edition. 

As  part  of  reinforcing  the  concept  of  detailed  subsidiary  plans  being  created  for  each  major  Knowledge 
Area  and  then  aggregated  into  the  overall  project  management  plan,  a new  process  was  added  for  Plan  Cost 
Management.  This  process  adds  focus  on  the  preliminary  decisions  around  developing  and  maintaining  the 
project’s  cost  estimates  and  budget.  Added  emphasis  was  placed  on  reserve  analysis  including  contingency  and 
management  reserves  with  a new  figure,  Figure  7-8,  added  to  illustrate  the  various  components  making  up  the 
project  budget.  A new  table,  Table  7-1  on  earned  value  calculations  summary,  was  added  to  collect  in  one  place 
all  of  the  formulas  used  for  earned  value  analysis.  Figures  for  earned  value  and  project  funding  requirements 
were  updated  to  reflect  the  added  emphasis  on  management  reserves.  Some  inputs  and  outputs  were  renamed 
for  several  processes  to  support  consistency  between  the  various  project  management  processes.  Inputs  and 
outputs  were  adjusted  for  several  processes  to  reflect  the  new  model  of  project  data  and  information  flow  during 
the  execution  of  project  work. 

The  following  table  summarizes  the  Section  7 processes: 


Table  XI -4.  Section  7 Changes 


Fourth  Edition  Sections 

Fifth  Edition  Sections 

7.1  Plan  Cost  Management 

7.1  Estimate  Costs 

7.2  Estimate  Costs 

7.2  Determine  Budget 

7.3  Determine  Budget 

7.3  Control  Cost 

7.4  Control  Costs 
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XI  .16  Section  8 — Project  Quality  Management  Changes 

No  new  processes  were  added  in  the  project  management  processes  contained  within  this  section.  The  Quality 
Planning  process  was  renamed  Plan  Quality  Management  to  support  consistency  in  naming  the  processes  that 
create  the  subsidiary  plans.  The  definition  for  Plan  Quality  Management  was  updated  to  better  align  with  the  added 
focus  on  quality  requirements  for  the  project.  The  Perform  Quality  Control  process  was  renamed  Control  Quality  to 
support  consistency  in  naming  the  various  controlling  processes.  Changes  consist  primarily  of  expanding  discussion 
on  various  tools  and  techniques  within  the  Quality  Management  processes.  Figure  8-2  on  IPECC  and  PDCA  Cycles 
in  Relation  to  QA,  QC,  and  COQ,  was  added  to  illustrate  the  fundamental  relationships  between  quality  assurance, 
quality  control,  and  cost  of  quality  to  the  Plan-Do-Check-Act  and  Initiate-Plan-Execute-Control-Close  models.  A 
new  input  was  added  for  the  Plan  Quality  Management  process  to  better  tie  the  requirements  gathered  during  the 
Collect  Requirements  process  to  the  overall  quality  planning  for  the  project.  More  emphasis  was  placed  on  the 
basic  quality  management  tools  used  in  managing  project  quality.  New  figures  were  added  to  better  summarize 
the  seven  basic  quality  tools  and  the  seven  quality  management  and  control  tools.  Some  inputs  and  outputs  were 
renamed  for  several  processes  to  support  consistency  between  the  various  project  management  processes.  Inputs 
and  outputs  were  adjusted  for  several  processes  to  reflect  the  new  model  of  project  data  and  information  flow 
during  the  execution  of  project  work. 

The  following  table  summarizes  the  Section  8 processes: 


Table  XI -5.  Section  8 Changes 


Fourth  Edition  Sections 

Fifth  Edition  Sections 

8.1  Plan  Quality 

8.1  Plan  Quality  Management 

8.2  Perform  Quality  Assurance 

8.2  Perform  Quality  Assurance 

8.3  Perform  Quality  Control 

8.3  Control  Quality 
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XI  .17  Section  9 — Project  Human  Resource  Management  Changes 

No  significant  changes  were  implemented  in  project  management  processes  contained  within  this  section. 
The  Human  Resource  Planning  process  was  renamed  Plan  Human  Resource  Management  to  support  consistency 
in  naming  the  processes  that  create  the  subsidiary  plans.  Changes  consist  primarily  of  some  added  or  modified 
inputs,  tools  and  techniques,  and  outputs,  and  the  replacement  of  project  management  plan  by  human  resource 
plan  as  an  input  of  processes  9.2  Acquire  Project  Team,  9.3  Develop  Project  Team,  and  9. 4. Manage  Project  Team 
for  consistency  with  processes  in  other  Knowledge  Areas.  The  definitions  for  Plan  Human  Resource  Management, 
Acquire  Project  Team,  and  Develop  Project  Team  were  updated  to  better  align  with  the  details  of  these  processes. 
Some  inputs  and  outputs  were  renamed  for  several  processes  to  support  consistency  in  how  information  flows 
between  the  various  project  management  processes. 

The  following  table  summarizes  the  Section  9 processes: 


Table  XI -6.  Section  9 Changes 


Fourth  Edition  Sections 

Fifth  Edition  Sections 

9.1  Develop  Human  Resource  Plan 

9.1  Plan  Human  Resource  Management 

9.2  Acquire  Project  Team 

9.2  Acquire  Project  Team 

9.3  Develop  Project  Team 

9.3  Develop  Project  Team 

9.4  Manage  Project  Team 

9.4  Manage  Project  Team 
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XI  .18  Section  10 — Project  Communications  Management  Changes 

Information  about  stakeholder  management  was  moved  from  Section  10  to  a new  Knowledge  Area  for 
Stakeholder  Management.  The  Plan  Communications  process  was  renamed  Plan  Communications  Management 
to  support  consistency  in  naming  the  processes  that  create  the  subsidiary  plans.  The  processes  for  Distribute 
Information  and  Report  Performance  were  reworked  to  clear  up  confusion  between  these  processes  and  their 
overlap  with  processes  for  Control  Scope,  Control  Schedule,  and  Control  Cost.  The  processes  were  refocused 
toward  the  activity  of  communication  as  performed  in  projects,  considering  more  the  process  of  communicating 
rather  than  the  intent  or  desired  outcome  of  the  message  with  emphasis  on  planning  for  the  communications 
needs  of  the  project,  collecting,  storing,  and  disseminating  project  information,  and  monitoring  overall  project 
communications  to  ensure  its  efficiency.  The  process  names  were  changed  to  Manage  Communications  and 
Control  Communications.  The  definitions  for  Plan  Communications  Management,  Manage  Communications, 
and  Control  Communications  were  updated  to  reflect  these  changes.  Some  inputs  and  outputs  were  renamed 
for  several  processes  to  support  consistency  between  the  various  project  management  processes.  Inputs  and 
outputs  were  adjusted  for  several  processes  to  reflect  the  new  model  of  project  data  and  information  flow  during 
the  execution  of  project  work. 

The  following  table  summarizes  the  Section  10  processes: 

Table  XI -7.  Section  10  Changes 


Fourth  Edition  Sections 

Fifth  Edition  Sections 

10.1  Identify  Stakeholders 

Moved  to  13.1 

10.2  Plan  Communications 

10.1  Plan  Communications  Management 

10.3  Distribute  Information 

10.2  Manage  Communications 

10.4  Manage  Stakeholder  Expectations 

Moved  to  13.3 

10.5  Report  Performance 

10.3  Control  Communications 
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XI  .19  Section  11 — Project  Risk  Management  Changes 

No  significant  changes  were  implemented  in  project  management  processes  contained  within  this  section. 
The  Monitor  and  Control  Risks  process  was  renamed  Control  Risks  to  support  consistency  in  naming  the  various 
controlling  processes.  Changes  were  made  to  move  the  emphasis  away  from  the  term  “positive  risks”  toward 
“opportunity”  to  better  align  with  the  feedback  from  the  project  management  community.  Text  was  added  to  expand 
upon  the  concepts  of  risk  attitude,  risk  appetite,  risk  tolerance,  and  risk  thresholds.  Other  changes  consist  primarily 
of  cleaning  up  text,  incorporating  feedback,  and  aligning  inputs  and  outputs  with  changes  from  other  Knowledge 
Areas.  Some  inputs  and  outputs  were  renamed  for  several  processes  to  support  consistency  between  the  various 
project  management  processes.  Inputs  and  outputs  were  adjusted  for  several  processes  to  reflect  the  new  model 
of  project  data  and  information  flow  during  the  execution  of  project  work. 

The  following  table  summarizes  the  Section  11  processes: 


Table  XI -8.  Section  11  Changes 


Fourth  Edition  Sections 

Fifth  Edition  Sections 

11.1  Plan  Risk  Management 

11.1  Plan  Risk  Management 

11.2  Identify  Risks 

11.2  Identify  Risks 

11.3  Perform  Qualitative  Risk  Analysis 

11.3  Perform  Qualitative  Risk  Analysis 

11.4  Perform  Quantitative  Risk  Analysis 

11.4  Perform  Quantitative  Risk  Analysis 

11.5  Plan  Risk  Responses 

11.5  Plan  Risk  Responses 

11.6  Monitor  and  Control  Risk 

11.6  Control  Risks 
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XI  .20  Section  12 — Project  Procurement  Management  Changes 

The  Plan  Procurements  process  was  renamed  Plan  Procurement  Management  to  support  consistency  in 
naming  the  processes  that  create  the  subsidiary  plans.  The  Administer  Procurement  process  was  renamed  Control 
Procurements  to  support  consistency  in  naming  the  various  controlling  processes.  Other  changes  consist  primarily 
of  cleaning  up  text,  incorporating  feedback,  and  aligning  inputs  and  outputs  with  changes  from  other  Knowledge 
Areas.  Some  inputs  and  outputs  were  renamed  for  several  processes  to  support  consistency  between  the  various 
project  management  processes.  Inputs  and  outputs  were  adjusted  for  several  processes  to  reflect  the  new  model 
of  project  data  and  information  flow  during  the  execution  of  project  work. 

The  following  table  summarizes  the  Section  12  processes: 


Table  XI -9.  Section  12  Changes 


Fourth  Edition  Sections 

Fifth  Edition  Sections 

12.1  Plan  Procurements 

12.1  Plan  Procurement  Management 

12.2  Conduct  Procurements 

12.2  Conduct  Procurements 

12.3  Administer  Procurements 

12.3  Control  Procurements 

12.4  Close  Procurements 

12.4  Close  Procurements 
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XI  .21  Section  13 — Project  Stakeholder  Management  Changes 

In  keeping  with  the  evolution  of  thinking  regarding  stakeholder  management  within  projects,  a new  Knowledge 
Area  was  added  addressing  Project  Stakeholder  Management.  Information  on  stakeholder  identification  and 
managing  stakeholder  expectations  was  moved  from  Section  10  on  Project  Communications  Management  to  this 
new  Knowledge  Area  to  expand  upon  and  increase  the  focus  on  the  importance  of  appropriately  engaging  project 
stakeholders  in  the  key  decisions  and  activities  associated  with  the  project.  New  processes  were  added  for  Plan 
Stakeholders  Management  and  Control  Stakeholders  Engagement.  Some  inputs  and  outputs  were  renamed  for 
several  processes  to  support  consistency  between  the  various  project  management  processes.  Inputs  and  outputs 
were  adjusted  for  several  processes  to  reflect  the  new  model  of  project  data  and  information  flow  during  the 
execution  of  project  work. 

The  following  table  summarizes  the  Section  13  processes: 


Table  XI -10.  Section  13  Changes 


Fourth  Edition  Sections 

Fifth  Edition  Sections 

10.1  Identify  Stakeholders 

13.1  Identify  Stakeholders 

13.2  Plan  Stakeholder  Management 

10.4  Manage  Stakeholders  Expectations 

13.3  Manage  Stakeholder  Engagement 

13.4  Control  Stakeholder  Engagement 
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XI  .22  Glossary 

The  glossary  of  the  PMS0/(®  Guide-  Fifth  Edition  has  been  expanded  and  updated  to  include  those  terms  within 
the  PMBOK®  Guide  that  need  to  be  defined  to  support  an  understanding  of  the  document’s  contents: 

• Clarify  meaning  and  improve  the  quality  and  accuracy  of  any  translations; 

• Eliminate  terms  not  used  within  the  PMBOK ® Guide-  Fifth  Edition;  and 

• Ensure  terms  align  and  harmonize  with  the  terms  in  the  PMI  Lexicon  and  other  key  PMI  standards. 

XI  .23  Data  Flow  Diagrams 

The  data  flow  diagrams  for  all  project  management  processes  were  cleaned  up  and  updated  to  remove 
inconsistencies  and  ensure  each  diagram  accurately  reflects  the  inputs  and  outputs  associated  with  a given  process. 
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APPENDIX  X2 

CONTRIBUTORS  AND  REVIEWERS  OF 
THE  PMBOK ® GUIDE—  FIFTH  EDITION: 


PMI  volunteers  first  attempted  to  codify  the  Project  Management  Body  of  Knowledge  in  the  Special  Report 
on  Ethics,  Standards,  and  Accreditation,  published  in  1983.  Since  that  time,  other  volunteers  have  come  forward 
to  update  and  improve  that  original  document  and  contribute  to  this  globally  recognized  standard  for  project 
management,  PMI’s  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK®  Guide).  This  appendix  lists, 
alphabetically  within  groupings,  those  individuals  who  have  contributed  to  the  development  and  production  of  the 
PMBOK ® Guide  - Fifth  Edition.  No  simple  list  or  even  multiple  lists  can  adequately  portray  all  the  contributions  of 
those  who  have  volunteered  to  develop  the  PMBOK®  Guide  - Fifth  Edition. 

The  Project  Management  Institute  is  grateful  to  all  of  these  individuals  for  their  support  and  acknowledges  their 
contributions  to  the  project  management  profession. 


X2.1  PMBOK®  Guide — Fifth  Edition  Core  Committee 

The  following  individuals  served  as  members,  were  contributors  of  text  or  concepts,  and  served  as  leaders 
within  the  Project  Core  Committee: 

The  following  individuals  served  as  members,  were  contributors  of  text  or  concepts,  and  served  as  leaders 
within  the  Project  Core  Committee: 

Dave  Violette,  MPM,  PMP,  Chair 
Joseph  W.  Kestel,  PMP,  Vice  Chair 
Nick  Clemens,  PMP  (Sections  3 and  4 Lead) 

Dan  Deakin,  PMP  (Sections  11  and  12  Lead) 

Theofanis  C.  Giotis,  PMP,  PMI-ACP  (Sections  1 and  2 Lead) 

Marie  A.  Gunnerson,  (Sections  6 and  7 Lead) 

Vanina  Mangano,  PMP,  PMI-RMP  (Integrated  Content  and  Change  Control  Lead) 

Mercedes  Martinez  Sanz,  PMP  (Sections  5 and  8 Lead) 

Carolina  Gabriela  Spindola,  PMP,  SSBB  (Quality  Control  Lead) 

Kristin  L.  Vitello,  CAPM,  Standards  Project  Specialist 
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X2.2  PMBOK®  Guide — Fifth  Edition  Subcommittee 

The  following  individuals  served  as  contributors  of  text  or  concepts  and  as  leaders  of  the  Project  Subcommittee: 

Matthew  B.  Anderson,  PMP,  PMI-ACP  (Section  4 Leader) 

Gilbert  B.  Asher,  MBA,  PMP  (Data  Flow  Working  Group  Leader) 

Brad  Bigelow,  PMP,  MSP  (Section  2 Leader) 

Cecilia  Boggi,  PMP  (Section  9 Leader) 

Bernardo  0.  Bustamante,  PE,  PMP  (Section  1 Leader) 

Akshata  Karanth,  PMP  (Section  6 Leader) 

David  L.  Keeney,  PMP,  CTT+  (Section  8 Leader) 

David  Kramer  (Section  12  Leader) 

Karthikeyan  Kumaraguru  MS,  PMP  (Section  1 1 Leader) 

Mary-Elizabeth  Larson,  PMP,  CBAP  (Section  5 Leader) 

Charles  J.  Lesko,  Jr.,  Ph.D.,  PMP  (Section  10  Leader) 

Claudia  Alex  Morris,  MBA,  PMP  (Editorial  Leader) 

John  M.  Nevison  (Section  7 Leader) 

M.K.Ramesh,  BE,  PMP  (Section  3 Leader  through  6/2011) 

Krupakar  Reddy,  PMP,  PRINCE2  Practitioner  (Section  3 Leader) 

Yad  Senapathy  (Section  4 Leader  through  6/2011) 

Anca  E.  Slusanschi,  MSc,  PMP  (Section  13  Leader) 


X2.3  Significant  Contributors 

In  addition  to  the  members  of  the  Project  Core  Committee  and  Subcommittee,  the  following  individuals  provided 
significant  input  or  concepts: 

George  F.  Burton  MBA,  PMP 
Tammy  Clark 

Joel  R.  Erickson,  MAcc,  PMP 
Stanistaw  Gasik,  PhD 
Ashok  Jain,  PMP,  CSM 
Andrea  Pantano,  PMP 
Federico  Roman  Demo,  PMP,  ITIL 
Anthony  Tsui,  MIT,  PMP 
Jennifer  L.  Walker,  PMP 
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X2.4  PMBOK®  Guide — Fifth  Edition  Content  Committee 

The  following  individuals  were  contributors  of  text  or  concepts  and  provided  recommendations  on  drafts  of  the 
PMBOK ® Guide — Fifth  Edition: 


Humayun  Akhtar,  PE,  PMP 

Puja  Kasariya,  PMP 

Mark  0.  Alexander,  P.Eng,  PMP 

Khalid  Ahmad  Khan,  PE,  PMP 

Miguel  Angel  Hernandez  Ayala,  MBA,  PMP 

Terri  Herman  Kimball,  PMP 

Katherine  A.  Barnoski,  PMP,  CPCP 

Vijay  Kumar 

Sameer  S.  Bendre,  PMP,  CSM 

Gaspar  Pacheco  Leal,  PMP 

Manuela  Borlovan 

Nguyen  Long  Son,  PMP,  PMI-RMP 

Hector  E.A.  Boye,  MSc,  PMP 

Debra  J.  Lovelace,  PMP 

Carlos  M.  Brenes,  MPM 

Tom  Magee,  MBA,  PMP 

Kevin  Brennan,  PMP,  CBAP 

Ahsan  Maqbool,  PMP,  PMI-RMP 

Melissa  F.  Bull,  PMP 

Conrado  Morlan,  PgMP,  PMP 

Guido  Caciagli  B.,  PMP 

Tilden  Moschetti 

Jesus  Mario  Garcia  Cano,  PMP 

Jacob  Kottackal  Ninan 

Ramesh  Chandak 

Abdul  Nsubuga 

Carol  Dekkers,  PMP,  CFPS 

Reuben  Oshomah,  MSc,  PMP 

Wayne  D.  Ellis,  PE,  PMP 

Marcus  S.  Parker  Sr.,  PMP 

Andres  Falcon,  MBA,  PMP 

Sergio  A.  Penaloza,  PMP 

Anna  Maria  Felici,  PMP,  CMC® 

Ute  Riemann,  MBA,  MCS 

Sachin  Ghai,  PMP 

Nick  Riordan,  MBA,  PMP 

Juan  Carlos  Gonzalez,  PMP,  ITIL 

Shivkanth  V.  Rohith,  PMP,  PMI-ACP 

Mike  Griffiths,  PMP,  PMI-ACP 

Bruce  Schwickrath,  PMP,  LSS-MBB 

Joseph  Gruber,  PMP,  CAPM 

Kishankumar  J.  Solanki 

Sharnikya  F.  Howard,  MBA,  PMP 

TejasV.  Sura,  MS,  PMP 

Harold  S.  Hunt,  PMP 

Federico  Vargas,  PMP,  MPM 

Suhail  Iqbal,  PgMP,  PMP 

Srikanth  Victory 

Rajan  T.  Janjani,  PMP,  ITIL  Expert 

Himanshu  Shripad  Warudkar,  PMP,  ITIL 

Chandrashekhar  S.  Joshi,  PMP, 

S.K.  Steve  Wong,  PMP,  CMA 

Chartered  Engineer 
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X2.5  Reviewers: 


X2.5.1  SME  Review 


In  addition  to  the  members  of  the  Committee,  the  following  individuals  provided  their  review  and  recommendations 
on  drafts  of  the  standard: 


Stephen  KwasiAgyei,  PMP,  LLM 
LavanyaArul,  PMP,  PMI-RMP 
Ernest  Baker,  PMP,  PRINCE2  Practitioner 
Mamoun  Besaiso,  CE 
James  C.  Bradford,  Jr.,  PMP 
Damiano  Bragantini,  PMP 
Georgeta  Brehoi,  PMP 
Peter  Brown 

Andrea  Caccamese,  PMP,  Prince2  Practitioner 

Panos  Chatzipanos,  PhD,  PE 

Jared  Curtis,  PMP 

Mario  C.  Delvas,  MBA,  PMP 

Dipti  Desai,  PMP 

Lakshmi  Dhruvarao,  PMP,  CSM 

George  Diakonikolaou,  PhD,  PMP 

Peter  Dimov,  PMP,  CBM 

Richard  Egelstaff,  PMP,  MBA 

Charles!  Follin,  PMP 

Prabhat  Garg,  PMP 

Vivek  Goel,  PMP,  CSM 

Mustafa  Hafizoglu 

Dr.  Sheriff  Hashem,  PhD,  PMP 

David  A.  Hillson,  PhD,  PMI  Fellow 

Christine  Floffman 

Hiroto  Horio,  PMP 

David!  Hulett,  PhD 

Poornaselvan  Jeevanandam 

Gregory  I.  Jepson 

Kazuo  Kawai,  PMP 


Konstantinos  Kirytopoulos,  PhD,  PMP 
Adrian  W.  Lovel-Hall,  PMP,  PMI-RMP 
Thomas  F.  McCabe,  PMP,  CSSMBB 
Harold  “Mike”  Mosley,  Jr.,  PE,  PMP 
Daud  Nasir,  PMP,  LSSBB 
Alexandre  Vieira  de  Oliveira,  MBA,  PMP 
SnehaV.  Patel,  PMP 
Richard  Perrin 
Walter  Plagge,  MBA,  PMP 
Marlene  Derian  Robertson 
Fernan  Rodriguez,  PMP 
!res  Roeder,  MBA,  PMP 
Guy  Schleffer,  MBA,  PgMP 
Nitin  Shende,  PMP,  CSM 
Nagendra  Sherman,  PMP 
J.  Greg  Smith 
Cyndi  Snyder,  PMP,  EVP 
Geree  V.  Streun,  PMP,  PMI-ACP 
Jurgen  Sturany,  PMP 
Yasuji  Suzuki,  PMP 
Shoji  !ajima 
Yvonne  Tan  EY,  PMP 
Gerhard  J.Tekes,  PMP,  PMI-OPM3 
Certified  Professional 
Biagio  Tramontana,  Eng.,  PMP 
Thomas  M.  Walsh,  PMP 
Juanita  M.  Woods,  PMP,  PgMP 
Ronaldo  Zanardo,  CAPM 
Heinz  Zimmermann,  PMP 
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X2.5.2  Member  Advisory  Group  (MAG)  Review 

The  following  individuals  served  as  members  of  the  PMI  Standards  Program  Member  Advisory  Group  and  voted 
on  the  final  draft  of  the  PMBOK ® Guide  - Fifth  Edition: 

Monique  Aubry,  PhD,  MPM 
Chris  Cartwright,  MPM,  PMP 
Laurence  Goldsmith,  PMP 
Paul  E.  Shaltry,  PMP 
Cyndi  Snyder,  MBA,  PMP,  EVP 

X2.5.3  Consensus  Body  Review 

The  following  individuals  served  as  members  of  the  PMI  Standards  Program  Consensus  Body  and  voted  on  the 
final  draft  of  the  PMBOK ® Guide  - Fifth  Edition: 

Monique  Aubry,  PhD,  MPM 
Nigel  Blampied,  PE,  PMP 
Nathalie  Bohbot,  PMP 
Dennis  L.  Bolles,  PMP 
Peggy  Brady 

Chris  Cartwright,  MPM,  PMP 
Sergio  Coronado,  PdD. 

Andrea  Demaria,  PMP 
John  L.  Dettbarn,  Jr.,  DSc,  PE 
Charles  T.  Follin,  PMP 
Laurence  Goldsmith,  MBA,  PMP 
Dana  J Goulston,  PMP 
Dorothy  L.  Kangas,  PMP 
Thomas  Kurihara 
Timothy  MacFadyen 

David  Christopher  Miles,  CEng,  0PM3-CC 
Harold  “Mike”  Mosley,  Jr.,  PE,  PMP 
Mike  Musial,  PMP,  CBM 
Eric  S.  Norman,  PgMP,  PMP 
Deborah  O’Bray,  CIM  (Hons) 
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Nanette  Patton,  MSBA,  PMP 

Crispin  (“Kik”)  Piney,  BSc,  PgMP 

Michael  Reed,  PMP 

Chris  Richards,  PMP 

Paul  E.  Shaltry,  PMP 

Jen  L.  Skrabak,  MBA,  PMP 

Matthew  D.  Tomlinson,  PgMP,  PMP 

X2.5.4  Final  Exposure  Draft  Review 

In  addition  to  the  members  of  the  Committee,  the  following  individuals  provided  recommendations  for  improving 
the  Exposure  Draft  of  the  PMBOK ® Guide — Fifth  Edition: 


Javed  A.  Abbasi,  MBA,  PMP 
Klaus  Abert 
Biju  B.  Abraham,  PMP 
Mohammad  I.  Abu  Irshaid,  PMP 
Mohammad  Adel,  PMP 
Yaser  Afaneh,  MSCE,  PMP 
Eng.  Ahmed  Taha,  MBA,  PMP 
Mounir  Ajam 

Phill  C.Akinwale,  MSc,  PMP 
Mfon  D.Akpan,  MBA,  PMP 
Mobasher  Abdu  Al-Asmry, 

CE,  KSA 

Homam  Al  khateeb,  PMP, 
PMI-RMP 

Ahmad  Al-Nahar,  MBA,  PMP 
Melad  Alaqra,  PMP 
Jose  Rafael  Alcala  Gomez, 
MBA,  PMP 

Martin  Aleman  Valdes,  PMP 
Mohammed  Faiq  Al-Hadeethi, 


PMP,  MSc  (Mech.) 

Anwar  AN,  MBA,  PMP 
Allam  VVSVenu,  PMP 
Barnabas  Seth  Amarteifio, 
PMP,  ITIL 
Yousif  Amin,  PMP 
Andy  Anderson,  MA,  PMP 
David  Angelow,  MBA,  PMP 
Luciano  Antoniucci 
Mark  A.  Archer,  PhD,  PMP 
Ondiappan  Arivazhagan  “Ari” 
PMP,  PMI-RMP 
Wisdom  Kwasi  Asare- 
Amegashie 
Babissakana,  PMP 
Mohamed  A.  Badie,  PMP, 
Prince2  Practitioner 
Ammar  N.  Baidas,  PgMP,  PMP 
Kamal  Bajaj,  PMP,  PGDBA 
Jehad  J.  Baker,  PgMP,  PMP 


J.  Balamurali,  PMP 

Federica  Ballone,  PMP 

Manuel  F.  BaqueroV.,  MSc,  PMP 

Brent  R.  Barton 

Anupam  Baruah 

Olaf  Baumgartner,  PMP 

lain  Begg,  PMP 

Laura  Benedetti 

Wayne  F.  Best 

Harwinder  Singh  Bhatia, 

PMP,  CSM 

Pius  Bienz,  PhD,  PMP 
Jean  Binder,  PMP 
Nigel  Blampied,  PE,  PMP 
Michael  P.  Bomi,  BSc,  PMP 
Raul  Borges,  PMP 
Farid  F.  Bouges,  MSc,  PMP 
Lynda  Bourne,  DPM,  FAIM 
Joao  Carlos  Boyadjian, 

MSc,  PMP 
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Didier  Brackx,  PMP 
Jim  Branden,  MBA,  PMP 
Wayne  R.  Brantley,  MSEd,  PMP 
Ralf  Braune,  PMP 
Tamela  J.  Brittingham,  PMP 
Jerry  Bucknoff,  MBA,  PMP 
SyedAsad  Hasnain  Bukhari, 

MBA  (MIS),  PMP 
Jeffrey  S.  Busch,  PMP 
Mario  Castro  Caballero 
Anthony  Cabri,  PMP 
Andrea  Caccamese,  PMP, 

Prince2  Practitioner 
Roberto  A.  Cadena  Legaspi,  PMP 
Jacob  Calabrese,  CSP,  CBAP 
Maria  Cardullo 
James  F.  Carilli,  PgMP,  PMP 
Christopher  W.  Carson, 

PMP,  CCM 

Angela  M.  Cason,  PMP 
Ralph  Celento 
Rebecca  Cervoni,  PMP 
Bruce  C.  Chadbourne, 

PgMP,  PMI-RMP 
Kameswaran 
Chandrasekaran,  PMP 
Theodore  Jiyon  Chang 
Ramesh  Chepur,  PMP,  PRINCE2 
Practitioner 

Subrahmanyam  VN  Chinta 
PMP,  CSM 

Marcin  Chomicz,  MBA,  PMP 
Abhishek  Chopra 


Angel  R.  Chourio,  PMP 
Eric  Christoph,  PMP,  EVP 
Rose  M.  Clark,  PMP 
Rogerio  L.  Clavello,  PMP 
Xavier  Clerfeuille,  MSc,  SSL 
Black  Belt 

Paul  Converti,  PMP,  CISSP 
Mario  Coquillat  de 
Travesedo,  PMP 
Franco  Cosenza,  PE,  MScEE 
Jeremy  Coster,  PMP 
Raymond  Covert 
Holly  Cowe 

Adriano  Jose  da  Silva  Neves, 
MSc,  PMP 

William  L.  (Bill)  Dam,  PMP,  CPG 
Joseph  W.  Daniel,  PMP 
Richard  Gary  Daniels 
Mohamed  Daoud 
Russell  W.  Darnall,  DM,  PMP 
Fariborz  Davarpanah,  MBA,  PMP 
Luiz  Guilherme  de  Carvalho 
Elisa  De  Mattia 
PH.  Manjula  Deepal  De  Silva, 
BSc,  PMP 
Vijay  Deshpande 
Salvatore  Di’iorio 
George  Diakonikolaou 
John  H.  Dittmer,  VI,  CISSP- 
ISSMP,  PMP 
Marcelo  Sans  Dodson, 

PMP,  MPM 

Roland  Doerr,  MBA,  PMP 


Serge  Dolivet,  PMP 
Bhushan  Dongare 
R.  Bernadine  Douglas,  MS,  PMP 
Xinhua  Du 
Arun  Dubagunta 
Stephen  Duffield,  MPM,  CPPD 
Pradip  Kumar  Dwevedi,  PMP 
HanyA.  Elhay,  PMP 
Bilal  M.  El  Itani,  MBA,  PMP 
Abdurazag  Elkhadrawe 
William  Ernest,  MPM,  PMP 
Dmitry  A.  Ezhov,  PMP 
Leandro  Faria,  PMP,  PMI-ACP 
Daniel  Fay,  PMP 
Madhu  Fernando,  DBA,  PMP 
Jesse  Fewell,  PMP,  CST 
Claudia  Fiallo,  PMP 
John  C. ‘Buck’  Field,  MBA,  PMP 
Robinson  Figueroa,  MS,  PMP 
David  Foley,  MBA 
Sandra  Fonseca-Lind 
Scott  D.  Freauf,  PMP,  IPMA-C 
Sakae  Fujino 
Yoichi  Fukuhara,  PMP 
Nestor  C.  Gabarda  Jr.,  ECE,  PMP 
Luca  Gambetti,  PMP,  CFPS 
Gerardo  A.  Garavito  F,  PMP, 
PMI-ACP 

Jose  Eduardo  Motta  Garcia, 
MBA,  PMP 

Jorge  Garcia  Solano,  PMP,  MPM 
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Sergio  Garon,  MS 
Jay  D.  Gassaway,  PMP,  PMP-SP 
Michael  J.  Gauthier,  MA,  CPM 
Darline  Georges 
Soumajit  (Sam)  Ghosh,  PMP, 
PhD  Candidate 

Carl  M.  Gilbert,  PMP,  Cert  0PM3 
Professional 

Peter  James  Gilliland,  PMP 
Sulema  de  Oliveira  Barcelos 
Gobato,  MsC,  PMP 
Emily  Godinet  Lounge,  PMP 
Peter  Goldberg 
Andres  F.  Gomez,  MSc,  PMP 
Guillermo  Gomez  Hdez.,  CSM 
Jose  Abranches  Gongalves, 
MSc,  PMP 

Himanshu  Kumar  Goswami 
Jean  Gouix,  Eng,  PgMP,  PMP 
Gary  J.  Graham,  CISM,  CISSP 
Charlie  Green,  PMP 
Roy  C.  Greenia,  MPM,  PMP 
Salomon  Pineda  Guerrero 
Pier  Luigi  Guida,  PgMP,  PMP 
LakshmeeshaT.  Gundurao, 

PMP,  CSM 

Guo  Ming-Hui  (MARS),  PMP 
Kapil  Gupta,  PMP 
Edward  Hall,  PMP 
Noha  Hamdy 

Sharad  S Harale,  MBA,  PMP 
Simon  Harris,  PMP,  D4® 
Accredited 


Abdulrahman  M Hassan,  MSc 
Gregory!  Haugan,  Sr., 

PhD,  PMP 

Larry  J.  Hawkins,  DSc,  PMP 
Susumu  Hayakawa,  PMP 
Kym  Henderson,  RFD 
MSc  (Comp) 

Robert  Hierholtz 
Robert  N.  Higgins  V,  PMP 
Danny  N.  Hinton,  PMP 
Shirley  P.  Hinton,  PMP 
Hisashi  Hirose,  PMP 
Jack  J.  Holmes,  PMP 
Keith  D.  Hornbacher,  MBA 
Tim  Hornett,  PMP 
Christina  M.  House,  PMP,  EMBA, 
Seth  Huckabee 
Robert  F.  Hull,  PE,  PMP 
Guillermo  A.  Ibanez,  PMP,  ITIL 
Shuichi  Ikeda,  PMP 
Hemant  Israni,  PMP,  PMI-RMP 
Vladimir  Ivanov,  IPMA-B 
Assessor,  ITIL  Expert 
Vidya  Iyer,  PMP 
Can  Izgi,  PMP 
Elaine  T.  Jackson,  BS,  PMP 
James  M.  Jackson,  PMP,  FLMI 
Rajesh  Jadhav,  PgMP,  PMI-RMP 
Rebecca  Jahelka,  PMP 
Gagan  Jain,  MBA,  PMP 
Don  R.  James,  PMP 
Vicki  James 
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APPENDIX  X3 
INTERPERSONAL  SKILLS 

Project  managers  accomplish  work  through  the  project  team  and  other  stakeholders.  Effective  project  managers 
acquire  a balance  of  technical,  interpersonal,  and  conceptual  skills  that  help  them  analyze  situations  and  interact 
appropriately.  This  appendix  describes  important  interpersonal  skills,  such  as: 

• Leadership 

• Team  building 

• Motivation 

• Communication 

• Influencing 

• Decision  making 

• Political  and  cultural  awareness 

• Negotiation 

• Trust  building 

• Conflict  management 

• Coaching 

While  there  are  additional  interpersonal  skills  that  project  managers  use,  the  appropriate  use  of  these  skills 
assists  the  project  manager  in  effectively  managing  the  project. 


X3.1  Leadership 

Leadership  involves  focusing  the  efforts  of  a group  of  people  toward  a common  goal  and  enabling  them  to 
work  as  a team.  In  general  terms,  leadership  is  the  ability  to  get  things  done  through  others.  Respect  and  trust, 
rather  than  fear  and  submission,  are  the  key  elements  of  effective  leadership.  Although  important  throughout  all 
project  phases,  effective  leadership  is  critical  during  the  beginning  phases  of  a project  when  the  emphasis  is  on 
communicating  the  vision  and  motivating  and  inspiring  project  participants  to  achieve  high  performance. 
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Throughout  the  project,  the  project  team  leaders  are  responsible  for  establishing  and  maintaining  the  vision, 
strategy,  and  communications;  fostering  trust  and  team  building;  influencing,  mentoring,  and  monitoring;  and 
evaluating  the  performance  of  the  team  and  the  project. 


X3.2  Team  Building 

Team  building  is  the  process  of  helping  a group  of  individuals,  bound  by  a common  purpose,  to  work  with  each 
other,  the  leader,  external  stakeholders,  and  the  organization. The  result  of  good  leadership  and  good  team  building 
is  teamwork. 

Team-building  activities  consist  of  tasks  (establish  goals,  define,  and  negotiate  roles,  responsibilities,  and 
procedures)  and  processes  (interpersonal  behavior  with  emphasis  on  communication,  conflict  management, 
motivation,  and  leadership).  Developing  a team  environment  involves  handling  project  team  problems  and 
discussing  these  as  team  issues  without  placing  blame  on  individuals.  Team  building  can  be  further  enhanced  by 
obtaining  top  management  support;  encouraging  team  member  commitment;  introducing  appropriate  rewards, 
recognition,  and  ethics;  creating  a team  identity;  managing  conflicts  effectively;  promoting  trust  and  open 
communication  among  team  members;  and  providing  leadership. 

While  team  building  is  essential  during  the  front  end  of  a project,  it  is  an  ongoing  process.  Changes  in  a project 
environment  are  inevitable.  To  manage  these  changes  effectively,  a continued  or  renewed  team-building  effort  is 
required.  Outcomes  of  team  building  include  mutual  trust,  high  quality  of  information  exchange,  better  decision 
making,  and  effective  project  management. 


X3.3  Motivation 

Projectteams  are  comprised  of  team  members  with  diverse  backgrounds,  expectations,  and  individual  objectives. 
The  overall  success  of  the  project  depends  upon  the  project  team’s  commitment,  which  is  directly  related  to  their 
level  of  motivation. 

Motivating  in  a project  environment  involves  creating  an  environment  to  meet  project  objectives  while  providing 
maximum  satisfaction  related  to  what  people  value  most.  These  values  may  include  job  satisfaction,  challenging 
work,  a sense  of  accomplishment,  achievement  and  growth,  sufficient  financial  compensation,  and  other  rewards 
and  recognition  the  individual  considers  necessary  and  important. 
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X3.4  Communication 

Communication  has  been  identified  as  one  of  the  single  biggest  reasons  for  project  success  or  failure.  Effective 
communication  within  the  project  team  and  between  the  project  manager,  team  members,  and  all  external 
stakeholders  is  essential.  Openness  in  communication  is  a gateway  to  teamwork  and  high  performance.  It  improves 
relationships  among  project  team  members  and  creates  mutual  trust. 

To  communicate  effectively,  the  project  manager  should  be  aware  of  the  communication  styles  of  other  parties, 
cultural  nuances/norms,  relationships,  personalities,  and  the  overall  context  of  the  situation.  Awareness  of  these 
factors  leads  to  mutual  understanding  and  thus  to  effective  communication.  Project  managers  should  identify 
various  communication  channels,  understand  what  information  they  need  to  provide,  what  information  they  need 
to  receive,  and  which  interpersonal  skills  will  help  them  communicate  effectively  with  various  project  stakeholders. 
Carrying  outteam-building  activities  to  determine  team  member  communications  styles  (e.g.,  directive,  collaborative, 
logical,  explorer,  etc.),  allows  managers  to  plan  their  communications  with  appropriate  sensitivity  to  relationships 
and  cultural  differences. 

Listening  is  an  important  part  of  communication.  Listening  techniques,  both  active  and  passive  give  the  user 
insight  to  problem  areas,  negotiation  and  conflict  management  strategies,  decision  making,  and  problem  resolution. 


X3.5  Influencing 

Influencing  is  a strategy  of  sharing  power  and  relying  on  interpersonal  skills  to  get  others  to  cooperate  towards 
common  goals.  Using  the  following  guidelines  can  influence  team  members: 

• Lead  by  example,  and  follow  through  with  commitments. 

• Clarify  how  a decision  will  be  made. 

• Use  a flexible  interpersonal  style  and  adjust  the  style  to  the  audience. 

Apply  your  power  skillfully  and  cautiously.  Think  of  long-term  collaboration. 
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X3.6  Decision  Making 

There  are  four  basic  decision  styles  normally  used  by  project  managers:  command,  consultation,  consensus, 
and  coin  flip  (random).  There  are  four  major  factors  that  affect  the  decision  style:  time  constraints,  trust,  quality, 
and  acceptance.  Project  managers  may  make  decisions  individually,  or  they  may  involve  the  project  team  in  the 
decision-making  process. 

Project  managers  and  project  teams  use  a decision-making  model  or  process  such  as  the  six-phase  model 
shown  below. 

• Problem  Definition.  Fully  explore,  clarify,  and  define  the  problem. 

• Problem  Solution  Generation.  Prolong  the  new  idea-generating  process  by  brainstorming  multiple 
solutions  and  discouraging  premature  decisions. 

• Ideas  to  Action.  Define  evaluation  criteria,  rate  pros  and  cons  of  alternatives,  select  best  solution. 

• Solution  Action  Planning.  Involve  key  participants  to  gain  acceptance  and  commitment  to  making  the 
solution  work. 

• Solution  Evaluation  Planning.  Perform  post-implementation  analysis,  evaluation,  and  lessons  learned. 

• Evaluation  of  the  Outcome  and  Process.  Evaluate  how  well  the  problem  was  solved  or  project  goals 
were  achieved  (extension  of  previous  phase). 


X3.7  Political  and  Cultural  Awareness 

Organizational  politics  are  inevitable  in  project  environments  due  to  the  diversity  in  norms,  backgrounds,  and 
expectations  of  the  people  involved  with  a project.  The  skillful  use  of  politics  and  power  helps  the  project  manager 
to  be  successful.  Conversely,  ignoring  or  avoiding  project  politics  and  inappropriate  use  of  power  can  lead  to 
difficulty  in  managing  projects. 

Today  project  managers  operate  in  a global  environment,  and  many  projects  exist  in  an  environment  of  cultural 
diversity.  By  understanding  and  capitalizing  on  cultural  differences,  the  project  management  team  is  more  likely 
to  create  an  environment  of  mutual  trust  and  a win-win  atmosphere.  Cultural  differences  can  be  both  individual 
and  corporate  in  nature  and  may  involve  both  internal  and  external  stakeholders.  An  effective  way  to  manage 
this  cultural  diversity  is  through  getting  to  know  the  various  team  members  and  the  use  of  good  communication 
planning  as  part  of  the  overall  project  plan. 
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Culture  at  a behavioral  level  includes  those  behaviors  and  expectations  that  occur  independently  of  geography, 
ethnic  heritage,  or  common  and  disparate  languages.  Culture  can  impact  the  speed  of  working,  the  decision- 
making process,  and  the  impulse  to  act  without  appropriate  planning.  This  may  lead  to  conflict  and  stress  in  some 
organizations,  thereby  affecting  the  performance  of  project  managers  and  project  teams. 

X3.8  Negotiation 

Negotiation  is  a strategy  of  conferring  with  parties  of  shared  or  opposed  interests  with  a view  toward  compromise 
or  reaching  an  agreement.  Negotiation  is  an  integral  part  of  project  management  and  done  well,  increases  the 
probability  of  project  success. 

The  following  skills  and  behaviors  are  useful  in  negotiating  successfully: 

• Analyze  the  situation. 

• Differentiate  between  wants  and  needs,  both  theirs  and  yours. 

• Focus  on  interests  and  issues  rather  than  on  positions. 

• Ask  high  and  offer  low,  but  be  realistic. 

• When  you  make  a concession,  act  as  if  you  are  yielding  something  of  value,  don’t  just  give  in. 

• Both  parties  should  feel  as  if  they  have  won.  This  win-win  negotiating  style  is  preferred  but  not 
always  achievable.  If  possible,  don’t  let  the  other  party  leave  feeling  as  though  he  or  she  has  been  taken 
advantage  of. 

• Listen  attentively  and  communicate  articulately. 


X3.9  Trust  Building 

The  ability  to  build  trust  across  the  project  team  and  other  key  stakeholders  is  a critical  component  in  effective 
team  leadership.  Trust  is  associated  with  cooperation,  information  sharing,  and  effective  problem  resolution.  Without 
trust  it  is  difficult  to  establish  the  positive  relationships  necessary  between  the  various  stakeholders  engaged  in  the 
project.  When  trust  is  compromised,  relationships  deteriorate,  people  disengage,  and  collaboration  becomes  more 
difficult,  if  not  impossible. 

Some  actions  project  managers  can  take  to  help  build  trust: 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK®  Guide)  - Fifth  Edition 


517 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


APPENDIX  X3  - INTERPERSONAL  SKILLS 


• Engage  in  open  and  direct  communications  to  resolve  problems. 

• Keep  all  stakeholders  informed,  especially  when  fulfilling  commitments  is  at  risk. 

• Spend  time  directly  engaged  with  the  team  asking  nonassumptive  questions  to  gain  a better  understanding 
of  the  situations  affecting  the  team. 

• Be  direct  and  explicit  about  what  you  need  or  expect. 

• Do  not  withhold  information  out  of  a fear  of  being  wrong  but  be  willing  to  share  information  even  if  you 
may  be  wrong. 

• Be  receptive  to  innovation  and  address  any  issues  or  concerns  in  a forthright  manner. 

• Look  beyond  your  own  interests. 

• Demonstrate  a true  concern  for  others  and  avoid  engaging  in  pursuits  that  could  be  viewed  as  being 
detrimental  to  the  interest  of  others. 

X3.10  Conflict  Management 

Conflict  is  inevitable  in  a project  environment.  Incongruent  requirements,  competition  for  resources,  breakdowns 
in  communications,  and  many  other  factors  could  become  sources  of  conflict.  Within  a project’s  environment, 
conflict  may  yield  dysfunctional  outcomes.  However,  if  actively  managed,  conflicts  can  actually  help  the  team  arrive 
at  a better  solution.  The  project  manager  must  be  able  to  identify  the  causes  for  conflict  and  then  actively  manage 
the  conflict  thus  minimizing  potential  negative  impacts.  The  project  team  is  then  able  to  deliver  better  solutions  and 
increase  the  probability  of  project  success. 

Project  managers  must  develop  the  skills  and  experience  necessary  to  effectively  adapt  their  personal  conflict 
management  style  to  the  situation.  Managing  conflict  in  a project  environment  involves  building  the  trust  necessary 
for  all  involved  parties  to  be  open  and  honest,  and  to  engage  in  seeking  a positive  resolution  to  the  situation  creating 
the  conflict.  Project  managers  strive  to  establish  a collaborative  approach  among  the  team  members  involved  in 
order  to  fully  resolve  the  problems.  In  situations  where  a collaborative  approach  is  not  possible,  the  project  manager 
must  then  revert  to  other  active  management  styles  for  handling  the  conflict;  e.g.,  assertiveness,  accommodation, 
avoidance,  or  compromise. 

Managing  conflict  is  one  of  the  biggest  challenges  a project  manager  faces.  It  draws  upon  all  of  the  other 
interpersonal  skills  of  a project  manager  in  order  to  lead  the  team  to  a successful  resolution  of  the  situation  in 
conflict. 
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X3.11  Coaching 

Coaching  is  a means  of  developing  the  project  team  to  higher  levels  of  competency  and  performance.  Coaching 
is  about  helping  people  recognize  their  potential  through  empowerment  and  development.  Coaching  is  used  to  aid 
team  members  in  developing  or  enhancing  their  skills  or  to  build  new  skills  required  to  enable  project  success. 
Coaching  can  take  many  forms  and  approaches.  In  some  instances,  formal  or  informal  training  may  be  developed 
to  increase  technical  skills  or  assist  team-building  efforts  and  facilitate  consistent  interpersonal  interactions. 

Coaching  is  also  used  to  address  poor  performance  and  to  help  team  members  overcome  deficiencies  in  their 
skill  sets.  Coaching  is  distinct  from  counseling.  Counseling  focuses  on  addressing  situations  where  team  members 
“won’t  do”  something  rather  than  “can’t  do.”  If  the  situation  is  one  where  the  team  member  is  not  performing  or 
meeting  expectations  due  to  a lack  of  skill,  knowledge,  or  experience,  coaching  can  be  employed  to  help  the  team 
member  to  develop  this  skill  and  thus  turn  a “can’t  do”  situation  into  one  of  “can  do.” 

Coaching  can  be  a powerful  motivator  for  teams.  As  teams  develop  their  skills,  abilities,  and  confidence,  their 
willingness  to  take  on  challenging  or  demanding  tasks  is  increased.  This  can  lead  to  more  effective  and  productive 
teams. 
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GLOSSARY 

1.  Inclusions  and  Exclusions 

This  glossary  includes  terms  that  are: 

• Unique  or  nearly  unique  to  project  management  (e.g.,  project  scope  statement,  work  package,  work 
breakdown  structure,  critical  path  method). 

• Not  unique  to  project  management,  but  used  differently  or  with  a narrower  meaning  in  project  management 
than  in  general  everyday  usage  (e.g.,  early  start  date,). 

This  glossary  generally  does  not  include: 

• Application  area-specific  terms. 

• Terms  used  in  project  management  which  do  not  differ  in  any  material  way  from  everyday  use 
(e.g.,  calendar  day,  delay). 

• Compound  terms  whose  meaning  is  clear  from  the  combined  meanings  of  the  component  parts. 

• Variants  when  the  meaning  of  the  variant  is  clear  from  the  base  term. 

As  a result  of  the  above  inclusions  and  exclusions,  this  glossary  includes: 

• A preponderance  of  terms  related  to  Project  Scope  Management,  Project  Time  Management,  and  Project 
Risk  Management,  since  many  of  the  terms  used  in  these  Knowledge  Areas  are  unique  or  nearly  unique 
to  project  management. 

• Many  terms  from  Project  Quality  Management,  since  these  terms  are  used  more  narrowly  than  in  their 
everyday  usage. 

• Relatively  few  terms  related  to  Project  Human  Resource  Management,  Project  Communications 
Management,  and  Project  Stakeholder  Management,  since  most  of  the  terms  used  in  these  Knowledge 
Areas  do  not  differ  significantly  from  everyday  usage. 

• Relatively  few  terms  related  to  Project  Cost  Management,  Project  Integration  Management,  and  Project 
Procurement  Management,  since  many  of  the  terms  used  in  these  Knowledge  Areas  have  narrow 
meanings  that  are  unique  to  a particular  application  area. 
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2.  Common  Acronyms 


AC 

actual  cost 

ACWP 

actual  cost  of  work  performed 

BAC 

budget  at  completion 

CCB 

change  control  board 

COQ 

cost  of  quality 

CPAF 

cost  plus  award  fee 

CPFF 

cost  plus  fixed  fee 

CPI 

cost  performance  index 

CPIF 

cost  plus  incentive  fee 

CPM 

critical  path  methodology 

CM 

cost  variance 

EAC 

estimate  at  completion 

EF 

early  finish  date 

EMV 

expected  monetary  value 

ES 

early  start  date 

ETC 

estimate  to  complete 

EV 

earned  value 

EVM 

earned  value  management 

FF 

finish-to-finish 

FFP 

firm  fixed  price  contract 

FMEA 

failure  mode  and  effect  analysis 

FP-EPA 

fixed  price  with  economic  price  adjustment 

FPIF 

fixed  price  incentive  fee 

FS 

finish  to  start 

524  ©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKB  Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


GLOSSARY 


IFB 

invitation  for  bid 

LF 

late  finish  date 

LOE 

level  of  effort 

LS 

late  start  date 

OBS 

organizational  breakdown  structure 

PDM 

precedence  diagramming  method 

PMBOK 

Project  Management  Body  of  Knowledge 

PV 

planned  value 

QFD 

quality  function  deployment 

RACI 

responsible,  accountable,  consult,  and  inform 

RAM 

responsibility  assignment  matrix 

RBS 

risk  breakdown  structure 

RFI 

request  for  information 

RFP 

request  for  proposal 

RFQ 

request  for  quotation 

SF 

start-to-finish 

SOW 

statement  of  work 

SPI 

schedule  performance  index 

SS 

start-to-start 

S V 

schedule  variance 

SWOT 

strengths,  weaknesses,  opportunities,  and  threats 

T&M 

time  and  material  contract 

WBS 

work  breakdown  structure 
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3.  Definitions 

Many  of  the  words  defined  here  have  broader,  and  in  some  cases  different,  dictionary  definitions. 

The  definitions  use  the  following  conventions: 

• In  some  cases,  a single  glossary  term  consists  of  multiple  words  (e.g.,  risk  urgency  assessment). 

• When  synonyms  are  included,  no  definition  is  given  and  the  reader  is  directed  to  the  preferred  term  (i.e., 
see  preferred  term). 

• Related  terms  that  are  not  synonyms  are  cross-referenced  at  the  end  of  the  definition  (i.e.,  see  also 
related  term). 

Acceptance  Criteria.  A set  of  conditions  that  is  required  to  be  met  before  deliverables  are  accepted. 

Accepted  Deliverables.  Products,  results,  or  capabilities  produced  by  a project  and  validated  by  the  project 
customer  or  sponsors  as  meeting  their  specified  acceptance  criteria. 

Accuracy.  Within  the  quality  management  system,  accuracy  is  an  assessment  of  correctness. 

Acquire  Project  Team.  The  process  of  confirming  human  resource  availability  and  obtaining  the  team  necessary 
to  complete  project  activities. 

Acquisition.  Obtaining  human  and  material  resources  necessary  to  perform  project  activities.  Acquisition  implies 
a cost  of  resources,  and  is  not  necessarily  financial. 

Activity.  A distinct,  scheduled  portion  of  work  performed  during  the  course  of  a project. 

Activity  Attributes.  Multiple  attributes  associated  with  each  schedule  activity  that  can  be  included  within  the  activity 
list.  Activity  attributes  include  activity  codes,  predecessor  activities,  successor  activities,  logical  relationships,  leads 
and  lags,  resource  requirements,  imposed  dates,  constraints,  and  assumptions. 

Activity  Code.  One  or  more  numerical  or  text  values  that  identify  characteristics  of  the  work  or  in  some  way 
categorize  the  schedule  activity  that  allows  filtering  and  ordering  of  activities  within  reports. 

Activity  Cost  Estimates.  The  projected  cost  of  the  schedule  activity  that  includes  the  cost  for  all  resources  required 
to  perform  and  complete  the  activity,  including  all  cost  types  and  cost  components. 

Activity  Duration.  The  time  in  calendar  units  between  the  start  and  finish  of  a schedule  activity.  See  also  duration. 
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Activity  Duration  Estimate.  A quantitative  assessment  of  the  likely  amount  or  outcome  for  the  duration  of  an 
activity. 

Activity  Identifier.  A short,  unique  numeric  or  text  identification  assigned  to  each  schedule  activity  to  differentiate 
that  project  activity  from  other  activities.  Typically  unique  within  any  one  project  schedule  network  diagram. 

Activity  List.  A documented  tabulation  of  schedule  activities  that  shows  the  activity  description,  activity  identifier, 
and  a sufficiently  detailed  scope  of  work  description  so  project  team  members  understand  what  work  is  to  be 
performed. 

Activity  Network  Diagrams.  See  project  schedule  network  diagram. 

Activity-on-Node  (AON).  See  precedence  diagramming  method  (PDM). 

Activity  Resource  Requirements.  The  types  and  quantities  of  resources  required  for  each  activity  in  a work 
package. 

Actual  Cost  (AC).  The  realized  cost  incurred  for  the  work  performed  on  an  activity  during  a specific  time  period. 

Actual  Duration.  The  time  in  calendar  units  between  the  actual  start  date  of  the  schedule  activity  and  either  the 
data  date  of  the  project  schedule  if  the  schedule  activity  is  in  progress  or  the  actual  finish  date  if  the  schedule 
activity  is  complete. 

Adaptive  Life  Cycle.  A project  life  cycle,  also  known  as  change-driven  or  agile  methods,  that  is  intended  to 
facilitate  change  and  require  a high  degree  of  ongoing  stakeholder  involvement.  Adaptive  life  cycles  are  also 
iterative  and  incremental,  but  differ  in  that  iterations  are  very  rapid  (usually  2-4  weeks  in  length)  and  are  fixed  in 
time  and  resources. 

Additional  Quality  Planning  Tools.  A set  of  tools  used  to  define  the  quality  requirements  and  to  plan  effective 
quality  management  activities.  They  include,  but  are  not  limited  to:  brainstorming,  force  field  analysis,  nominal 
group  techniques  and  quality  management  and  control  tools. 

Adjusting  Leads  and  Lags.  A technique  used  to  find  ways  to  bring  project  activities  that  are  behind  into  alignment 
with  plan  during  project  execution. 

Advertising.  The  process  of  calling  public  attention  to  a project  or  effort. 
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Affinity  Diagram.  A group  creativity  technique  that  allows  large  numbers  of  ideas  to  be  classified  into  groups  for 
review  and  analysis. 

Agreements.  Any  document  or  communication  that  defines  the  initial  intentions  of  a project.  This  can  take  the 
form  of  a contract,  memorandum  of  understanding  (MOU),  letters  of  agreement,  verbal  agreements,  email,  etc. 

Alternative  Analysis.  A technique  used  to  evaluate  identified  options  in  order  to  select  which  options  or 
approaches  to  use  to  execute  and  perform  the  work  of  the  project. 

Alternatives  Generation.  A technique  used  to  develop  as  many  potential  options  as  possible  in  order  to  identify 
different  approaches  to  execute  and  perform  the  work  of  the  project. 

Analogous  Estimating.  A technique  for  estimating  the  duration  or  cost  of  an  activity  or  a project  using  historical 
data  from  a similar  activity  or  project. 

Analytical  Techniques.  Various  techniques  used  to  evaluate,  analyze,  or  forecast  potential  outcomes  based  on 
possible  variations  of  project  or  environmental  variables  and  their  relationships  with  other  variables. 

Application  Area.  A category  of  projects  that  have  common  components  significant  in  such  projects, 
but  are  not  needed  or  present  in  all  projects.  Application  areas  are  usually  defined  in  terms  of  either  the 
product  (i.e.,  by  similar  technologies  or  production  methods)  or  the  type  of  customer  (i.e.,  internal  versus 
external,  government  versus  commercial)  or  industry  sector  (i.e.,  utilities,  automotive,  aerospace,  information 
technologies,  etc.).  Application  areas  can  overlap. 

Applying  Leads  and  Lags.  A technique  that  is  used  to  adjust  the  amount  of  time  between  predecessor  and 
successor  activities. 

Apportioned  Effort.  An  activity  where  effort  is  allotted  proportionately  across  certain  discrete  efforts  and  not 
divisible  into  discrete  efforts.  [Note:  Apportioned  effort  is  one  of  three  earned  value  management  (EVM)  types  of 
activities  used  to  measure  work  performance.] 

Approved  Change  Request.  A change  request  that  has  been  processed  through  the  integrated  change  control 
process  and  approved. 

Approved  Change  Requests  Review.  A review  of  the  change  requests  to  verify  that  these  were  implemented  as 
approved. 
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Assumption.  A factor  in  the  planning  process  that  is  considered  to  be  true,  real,  or  certain,  without  proof  or 
demonstration. 

Assumptions  Analysis.  A technique  that  explores  the  accuracy  of  assumptions  and  identifies  risks  to  the  project 
from  inaccuracy,  inconsistency,  or  incompleteness  of  assumptions. 

Attribute  Sampling.  Method  of  measuring  quality  that  consists  of  noting  the  presence  (or  absence)  of  some 
characteristic  (attribute)  in  each  of  the  units  under  consideration.  After  each  unit  is  inspected,  the  decision  is  made 
to  accept  a lot,  reject  it,  or  inspect  another  unit. 

Authority.  The  right  to  apply  project  resources,  expend  funds,  make  decisions,  or  give  approvals. 

Backlog.  A listing  of  product  requirements  and  deliverables  to  be  completed,  written  as  stories,  and  prioritized 
by  the  business  to  manage  and  organize  the  project’s  work. 

Backward  Pass.  A critical  path  method  technique  for  calculating  the  late  start  and  late  finish  dates  by  working 
backward  through  the  schedule  model  from  the  project  end  date. 

Bar  Chart.  A graphic  display  of  schedule-related  information.  In  the  typical  bar  chart,  schedule  activities  or  work 
breakdown  structure  components  are  listed  down  the  left  side  of  the  chart,  dates  are  shown  across  the  top,  and 
activity  durations  are  shown  as  date-placed  horizontal  bars.  See  also  Gantt  chart. 

Baseline.  The  approved  version  of  a work  product  that  can  be  changed  only  through  formal  change  control 
procedures  and  is  used  as  a basis  for  comparison. 

Basis  of  Estimates.  Supporting  documentation  outlining  the  details  used  in  establishing  project  estimates  such  as 
assumptions,  constraints,  level  of  detail,  ranges,  and  confidence  levels. 

Benchmarking.  Benchmarking  is  the  comparison  of  actual  or  planned  practices,  such  as  processes  and  operations, 
to  those  of  comparable  organizations  to  identify  best  practices,  generate  ideas  for  improvement,  and  provide  a 
basis  for  measuring  performance. 

Bidder  Conference.  The  meetings  with  prospective  sellers  prior  to  the  preparation  of  a bid  or  proposal  to  ensure 
all  prospective  vendors  have  a clear  and  common  understanding  of  the  procurement.  Also  known  as  contractor 
conferences,  vendor  conferences,  or  pre-bid  conferences. 
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Bottom-Up  Estimating.  A method  of  estimating  project  duration  or  cost  by  aggregating  the  estimates  of  the 
lower-level  components  of  the  work  breakdown  structure  (WBS). 

Brainstorming.  A general  data  gathering  and  creativity  technique  that  can  be  used  to  identify  risks,  ideas,  or 
solutions  to  issues  by  using  a group  of  team  members  or  subject  matter  experts. 

Budget.  The  approved  estimate  for  the  project  or  any  work  breakdown  structure  component  or  any  schedule 
activity. 

Budget  at  Completion  (BAC).  The  sum  of  all  budgets  established  for  the  work  to  be  performed. 

Buffer.  See  reserve. 

Business  Case.  A documented  economic  feasibility  study  used  to  establish  validity  of  the  benefits  of  a selected 
component  lacking  sufficient  definition  and  that  is  used  as  a basis  forthe  authorization  of  further  project  management 
activities. 

Business  Value.  A concept  that  is  unique  to  each  organization  and  includes  tangible  and  intangible  elements. 
Through  the  effective  use  of  project,  program,  and  portfolio  management  disciplines,  organizations  will  possess  the 
ability  to  employ  reliable,  established  processes  to  meet  enterprise  objectives  and  obtain  greater  business  value 
from  their  investments. 

Buyer.  The  acquirer  of  products,  services,  or  results  for  an  organization. 

Cause  and  Effect  Diagram.  A decomposition  technique  that  helps  trace  an  undesirable  effect  back  to  its  root 
cause. 

Central  Tendency.  A property  of  the  central  limit  theorem  predicting  that  the  data  observations  in  a distribution 
will  tend  to  group  around  a central  location.  The  three  typical  measures  of  central  tendency  are  the  mean,  median, 
and  mode. 

Change  Control.  A process  whereby  modifications  to  documents,  deliverables,  or  baselines  associated  with  the 
project  are  identified,  documented,  approved,  or  rejected. 

Change  Control  Board  (CCB).  A formally  chartered  group  responsible  for  reviewing,  evaluating,  approving, 
delaying,  or  rejecting  changes  to  the  project,  and  for  recording  and  communicating  such  decisions. 
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Change  Control  System.  A set  of  procedures  that  describes  how  modifications  to  the  project  deliverables  and 
documentation  are  managed  and  controlled. 

Change  Control  Tools.  Manual  or  automated  tools  to  assist  with  change  and/or  configuration  management.  At  a 
minimum,  the  tools  should  support  the  activities  of  the  CCB. 

Change  Log.  A comprehensive  list  of  changes  made  during  the  project.  This  typically  includes  dates  of  the  change 
and  impacts  in  terms  of  time,  cost,  and  risk. 

Change  Request.  A formal  proposal  to  modify  any  document,  deliverable,  or  baseline. 

Charter.  See  project  charter. 

Checklist  Analysis.  A technique  for  systematically  reviewing  materials  using  a list  for  accuracy  and  completeness. 
Checksheets.  A tally  sheet  that  can  be  used  as  a checklist  when  gathering  data. 

Claim.  A request,  demand,  or  assertion  of  rights  by  a seller  against  a buyer,  or  vice  versa,  for  consideration, 
compensation,  or  payment  under  the  terms  of  a legally  binding  contract,  such  as  for  a disputed  change. 

Claims  Administration.  The  process  of  processing,  adjudicating,  and  communicating  contract  claims. 

Close  Procurements.  The  process  of  completing  each  project  procurement. 

Close  Project  or  Phase.  The  process  of  finalizing  all  activities  across  all  of  the  Project  Management  Process 
Groups  to  formally  complete  a project  or  phase. 

Closed  Procurements.  Project  contracts  or  other  procurement  agreements  that  have  been  formally  acknowledged 
by  the  proper  authorizing  agent  as  being  finalized  and  signed  off. 

Closing  Process  Group.  Those  processes  performed  to  finalize  all  activities  across  all  Process  Groups  to  formally 
close  a project  or  phase. 

Code  of  Accounts.  A numbering  system  used  to  uniquely  identify  each  component  of  the  work  breakdown 
structure  (WBS). 

Collect  Requirements.  The  process  of  determining,  documenting,  and  managing  stakeholder  needs  and 
requirements  to  meet  project  objectives. 
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Colocation.  An  organizational  placement  strategy  where  the  project  team  members  are  physically  located 
close  to  one  another  in  order  to  improve  communication,  working  relationships,  and  productivity. 

Communication  Constraints.  Restrictions  on  the  content,  timing,  audience,  or  individual  who  will  deliver  a 
communication  usually  stemming  from  specific  legislation  or  regulation,  technology,  or  organizational  policies. 

Communication  Methods.  A systematic  procedure,  technique,  or  process  used  to  transfer  information  among 
project  stakeholders. 

Communication  Models.  A description,  analogy  or  schematic  used  to  represent  how  the  communication 
process  will  be  performed  for  the  project. 

Communication  Requirements  Analysis.  An  analytical  technique  to  determine  the  information  needs  of  the 
project  stakeholders  through  interviews,  workshops,  study  of  lessons  learned  from  previous  projects,  etc. 

Communication  Technology.  Specific  tools,  systems,  computer  programs,  etc.,  used  to  transfer  information 
among  project  stakeholders. 

Communications  Management  Plan.  A component  of  the  project,  program,  or  portfolio  management  plan  that 
describes  how,  when,  and  by  whom  information  about  the  project  will  be  administered  and  disseminated. 

Compliance.  A general  concept  of  conforming  to  a rule,  standard,  law,  or  requirement  such  that  the  assessment  of 
compliance  results  in  a binomial  result  stated  as  “compliant”  or  “noncompliant.” 

Conduct  Procurements.  The  process  of  obtaining  seller  responses,  selecting  a seller,  and  awarding  a contract. 

Configuration  Management  System.  A subsystem  of  the  overall  project  management  system.  It  is  a collection 
of  formal  documented  procedures  used  to  apply  technical  and  administrative  direction  and  surveillance  to: 
identify  and  document  the  functional  and  physical  characteristics  of  a product,  result,  service,  or  component; 
control  any  changes  to  such  characteristics;  record  and  report  each  change  and  its  implementation  status;  and 
support  the  audit  of  the  products,  results,  or  components  to  verify  conformance  to  requirements.  It  includes  the 
documentation,  tracking  systems,  and  defined  approval  levels  necessary  for  authorizing  and  controlling  changes. 

Conflict  Management.  Handling,  controlling,  and  guiding  a conflictual  situation  to  achieve  a resolution. 

Conformance.  Within  the  quality  management  system,  conformance  is  a general  concept  of  delivering  results  that 
fall  within  the  limits  that  define  acceptable  variation  for  a quality  requirement. 
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Conformance  Work.  In  the  cost  of  quality  framework,  conformance  work  is  done  to  compensate  for  imperfections 
that  prevent  organizations  from  completing  planned  activities  correctly  as  essential  first-time  work.  Conformance 
work  consists  of  actions  that  are  related  to  prevention  and  inspection. 

Constraint.  A limiting  factor  that  affects  the  execution  of  a project,  program,  portfolio,  or  process. 

Context  Diagrams.  A visual  depiction  of  the  product  scope  showing  a business  system  (process,  equipment, 
computer  system,  etc.),  and  how  people  and  other  systems  (actors)  interact  with  it. 

Contingency.  An  event  or  occurrence  that  could  affect  the  execution  of  the  project  that  may  be  accounted  for 
with  a reserve. 

Contingency  Allowance.  See  reserve. 

Contingency  Reserve.  Budget  within  the  cost  baseline  or  performance  measurement  baseline  that  is  allocated  for 
identified  risks  that  are  accepted  and  for  which  contingent  or  mitigating  responses  are  developed. 

Contingent  Response  Strategies.  Responses  provided  which  may  be  used  in  the  event  that  a specific  trigger 
occurs. 

Contract.  A contract  is  a mutually  binding  agreement  that  obligates  the  seller  to  provide  the  specified  product 
or  service  or  result  and  obligates  the  buyer  to  pay  for  it. 

Contract  Change  Control  System.  The  system  used  to  collect,  track,  adjudicate,  and  communicate  changes  to  a 
contract. 

Control.  Comparing  actual  performance  with  planned  performance,  analyzing  variances,  assessing  trends  to 
effect  process  improvements,  evaluating  possible  alternatives,  and  recommending  appropriate  corrective  action 
as  needed. 

Control  Account.  A management  control  point  where  scope,  budget,  actual  cost,  and  schedule  are  integrated  and 
compared  to  earned  value  for  performance  measurement. 

Control  Chart.  A graphic  display  of  process  data  over  time  and  against  established  control  limits,  which  has  a 
centerline  that  assists  in  detecting  a trend  of  plotted  values  toward  either  control  limit. 

Control  Communications.  The  process  of  monitoring  and  controlling  communications  throughout  the  entire  project 
life  cycle  to  ensure  the  information  needs  of  the  project  stakeholders  are  met. 
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Control  Costs.  The  process  of  monitoring  the  status  of  the  project  to  update  the  project  costs  and  managing 
changes  to  the  cost  baseline. 

Control  Limits.  The  area  composed  of  three  standard  deviations  on  either  side  of  the  centerline  or  mean  of  a 
normal  distribution  of  data  plotted  on  a control  chart,  which  reflects  the  expected  variation  in  the  data.  See  also 
specification  limits. 

Control  Procurements.  The  process  of  managing  procurement  relationships,  monitoring  contract  performance, 
and  making  changes  and  corrections  as  appropriate. 

Control  Quality.  The  process  of  monitoring  and  recording  results  of  executing  the  quality  activities  to  assess 
performance  and  recommend  necessary  changes. 

Control  Risks.  The  process  of  implementing  risk  response  plans,  tracking  identified  risks,  monitoring  residual 
risks,  identifying  new  risks,  and  evaluating  risk  process  effectiveness  throughout  the  project. 

Control  Schedule.  The  process  of  monitoring  the  status  of  project  activities  to  update  project  progress  and  manage 
changes  to  the  schedule  baseline  to  achieve  the  plan. 

Control  Scope.  The  process  of  monitoring  the  status  of  the  project  and  product  scope  and  managing  changes  to 
the  scope  baseline. 

Control  Stakeholder  Engagement.  The  process  of  monitoring  overall  project  stakeholder  relationships  and 
adjusting  strategies  and  plans  for  engaging  stakeholders. 

Corrective  Action.  An  intentional  activity  that  realigns  the  performance  of  the  project  work  with  the  project 
management  plan. 

Cost  Aggregation.  Summing  the  lower-level  cost  estimates  associated  with  the  various  work  packages  for  a 
given  level  within  the  project’s  WBS  or  for  a given  cost  control  account. 

Cost  Baseline.  The  approved  version  of  the  time-phased  project  budget,  excluding  any  management  reserves, 
which  can  be  changed  only  through  formal  change  control  procedures  and  is  used  as  a basis  for  comparison  to 
actual  results. 

Cost  Management  Plan.  A component  of  a project  or  program  management  plan  that  describes  how  costs  will 
be  planned,  structured,  and  controlled. 
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Cost  of  Quality.  A method  of  determining  the  costs  incurred  to  ensure  quality.  Prevention  and  appraisal  costs 
(cost  of  conformance)  include  costs  for  quality  planning,  quality  control  (QC),  and  quality  assurance  to  ensure 
compliance  to  requirements  (i.e.,  training,  QC  systems,  etc.).  Failure  costs  (cost  of  nonconformance)  include  costs 
to  rework  products,  components,  or  processes  that  are  non-compliant,  costs  of  warranty  work  and  waste,  and  loss 
of  reputation. 

Cost  Performance  Index  (CPI).  A measure  of  the  cost  efficiency  of  budgeted  resources  expressed  as  the  ratio  of 
earned  value  to  actual  cost. 

Cost  Plus  Award  Fee  Contracts  (CPAF).  A category  of  contract  that  involves  payments  to  the  seller  for  all  legitimate 
actual  costs  incurred  for  completed  work,  plus  an  award  fee  representing  seller  profit. 

Cost  Plus  Fixed  Fee  Contract  (CPFF).  A type  of  cost-reimbursable  contract  where  the  buyer  reimburses  the  seller 
for  the  seller’s  allowable  costs  (allowable  costs  are  defined  by  the  contract)  plus  a fixed  amount  of  profit  (fee). 

Cost  Plus  Incentive  Fee  Contract  (CPIF).  A type  of  cost-reimbursable  contract  where  the  buyer  reimburses  the 
seller  for  the  seller’s  allowable  costs  (allowable  costs  are  defined  by  the  contract),  and  the  seller  earns  its  profit  if 
it  meets  defined  performance  criteria. 

Cost  Variance  (CV).  The  amount  of  budget  deficit  or  surplus  at  a given  point  in  time,  expressed  as  the  difference 
between  the  earned  value  and  the  actual  cost. 

Cost-Benefit  Analysis.  A financial  analysis  tool  used  to  determine  the  benefits  provided  by  a project  against  its 
costs. 

Cost-Reimbursable  Contract.  A type  of  contract  involving  payment  to  the  seller  for  the  seller’s  actual  costs,  plus 
a fee  typically  representing  seller’s  profit.  Cost-reimbursable  contracts  often  include  incentive  clauses  where,  if  the 
seller  meets  or  exceeds  selected  project  objectives,  such  as  schedule  targets  or  total  cost,  then  the  seller  receives 
from  the  buyer  an  incentive  or  bonus  payment. 

Crashing.  A technique  used  to  shorten  the  schedule  duration  for  the  least  incremental  cost  by  adding 
resources. 

Create  WBS.  The  process  of  subdividing  project  deliverables  and  project  work  into  smaller,  more  manageable 
components. 
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Criteria.  Standards,  rules,  or  tests  on  which  a judgment  or  decision  can  be  based  or  by  which  a product,  service, 
result,  or  process  can  be  evaluated. 

Critical  Chain  Method.  A schedule  method  that  allows  the  project  team  to  place  buffers  on  any  project  schedule 
path  to  account  for  limited  resources  and  project  uncertainties. 

Critical  Path.  The  sequence  of  activities  that  represents  the  longest  path  through  a project,  which  determines  the 
shortest  possible  duration. 

Critical  Path  Activity.  Any  activity  on  the  critical  path  in  a project  schedule. 

Critical  Path  Method.  A method  used  to  estimate  the  minimum  project  duration  and  determine  the  amount  of 
scheduling  flexibility  on  the  logical  network  paths  within  the  schedule  model. 

Customer.  Customer  is  the  person(s)  or  organization(s)  that  will  pay  for  the  project’s  product,  service,  or  result. 
Customers  can  be  internal  or  external  to  the  performing  organization. 

Customer  Satisfaction.  Within  the  quality  management  system,  a state  of  fulfillment  in  which  the  needs  of  a 
customer  are  met  or  exceeded  for  the  customer’s  expected  experiences  as  assessed  by  the  customer  at  the 
moment  of  evaluation. 

Data  Date.  A point  in  time  when  the  status  of  the  project  is  recorded. 

Data  Gathering  and  Representation  Techniques.  Techniques  used  to  collect,  organize,  and  present  data  and 
information. 

Decision  Tree  Analysis.  A diagramming  and  calculation  technique  for  evaluating  the  implications  of  a chain  of 
multiple  options  in  the  presence  of  uncertainty. 

Decomposition.  A technique  used  for  dividing  and  subdividing  the  project  scope  and  project  deliverables  into 
smaller,  more  manageable  parts. 

Defect.  An  imperfection  or  deficiency  in  a project  component  where  that  component  does  not  meet  its 
requirements  or  specifications  and  needs  to  be  either  repaired  or  replaced. 

Defect  Repair.  An  intentional  activity  to  modify  a nonconforming  product  or  product  component. 

Define  Activities.  The  process  of  identifying  and  documenting  the  specific  actions  to  be  performed  to  produce  the 
project  deliverables. 
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Define  Scope.  The  process  of  developing  a detailed  description  of  the  project  and  product. 

Deliverable.  Any  unique  and  verifiable  product,  result,  or  capability  to  perform  a service  that  is  required  to  be 
produced  to  complete  a process,  phase,  or  project. 

Delphi  Technique.  An  information  gathering  technique  used  as  a way  to  reach  a consensus  of  experts  on  a 
subject.  Experts  on  the  subject  participate  in  this  technique  anonymously.  A facilitator  uses  a questionnaire  to 
solicit  ideas  about  the  important  project  points  related  to  the  subject.  The  responses  are  summarized  and  are 
then  recirculated  to  the  experts  for  further  comment.  Consensus  may  be  reached  in  a few  rounds  of  this  process. 
The  Delphi  technique  helps  reduce  bias  in  the  data  and  keeps  any  one  person  from  having  undue  influence  on 
the  outcome. 

Dependency.  See  logical  relationship. 

Dependency  Determination.  A technique  used  to  identify  the  type  of  dependency  that  is  used  to  create  the  logical 
relationships  between  predecessor  and  successor  activities. 

Design  of  Experiments.  A statistical  method  for  identifying  which  factors  may  influence  specific  variables  of  a 
product  or  process  under  development  or  in  production. 

Determine  Budget.  The  process  of  aggregating  the  estimated  costs  of  individual  activities  or  work  packages  to 
establish  an  authorized  cost  baseline. 

Develop  Project  Charter.  The  process  of  developing  a document  that  formally  authorizes  the  existence  of  a project 
and  provides  the  project  manager  with  the  authority  to  apply  organizational  resources  to  project  activities. 

Develop  Project  Management  Plan.  The  process  of  defining,  preparing,  and  coordinating  all  subsidiary  plans  and 
integrating  them  into  a comprehensive  project  management  plan. 

Develop  Project  Team.  The  process  of  improving  competencies,  team  member  interaction,  and  overall  team 
environment  to  enhance  project  performance. 

Develop  Schedule.  The  process  of  analyzing  activity  sequences,  durations,  resource  requirements,  and  schedule 
constraints  to  create  the  project  schedule  model. 

Diagramming  Techniques.  Approaches  to  presenting  information  with  logical  linkages  that  aid  in  understanding. 
Dictatorship.  A group  decision-making  technique  in  which  one  individual  makes  the  decision  for  the  group. 
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Direct  and  Manage  Project  Work.  The  process  of  leading  and  performing  the  work  defined  in  the  project 
management  plan  and  implementing  approved  changes  to  achieve  the  project’s  objectives. 

Discrete  Effort.  An  activity  that  can  be  planned  and  measured  and  that  yields  a specific  output.  [Note:  Discrete 
effort  is  one  of  three  earned  value  management  (EVM)  types  of  activities  used  to  measure  work  performance.] 

Discretionary  Dependency.  A relationship  that  is  established  based  on  knowledge  of  best  practices  within  a 
particular  application  area  or  an  aspect  of  the  project  where  a specific  sequence  is  desired. 

Document  Analysis.  An  elicitation  technique  that  analyzes  existing  documentation  and  identifies  information 
relevant  to  the  requirements. 

Documentation  Reviews.  The  process  of  gathering  a corpus  of  information  and  reviewing  it  to  determine  accuracy 
and  completeness. 

Duration  (DU  or  DUR).  The  total  number  of  work  periods  (not  including  holidays  or  other  nonworking  periods) 
required  to  complete  a schedule  activity  or  work  breakdown  structure  component.  Usually  expressed  as  workdays 
or  workweeks.  Sometimes  incorrectly  equated  with  elapsed  time.  Contrast  with  effort. 

Early  Finish  Date  (EF).  In  the  critical  path  method,  the  earliest  possible  point  in  time  when  the  uncompleted 
portions  of  a schedule  activity  can  finish  based  on  the  schedule  network  logic,  the  data  date,  and  any  schedule 
constraints. 

Early  Start  Date  (ES).  In  the  critical  path  method,  the  earliest  possible  point  in  time  when  the  uncompleted 
portions  of  a schedule  activity  can  start  based  on  the  schedule  network  logic,  the  data  date,  and  any  schedule 
constraints. 

Earned  Value  (EV).  The  measure  of  work  performed  expressed  in  terms  of  the  budget  authorized  for  that  work. 

Earned  Value  Management.  A methodology  that  combines  scope,  schedule,  and  resource  measurements  to 
assess  project  performance  and  progress. 

Effort.  The  number  of  labor  units  required  to  complete  a schedule  activity  or  work  breakdown  structure  component, 
often  expressed  in  hours,  days,  or  weeks. 

Emotional  Intelligence.  The  capability  to  identify,  assess,  and  manage  the  personal  emotions  of  oneself  and  other 
people,  as  well  as  the  collective  emotions  of  groups  of  people. 
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Enterprise  Environmental  Factors.  Conditions,  not  under  the  immediate  control  of  the  team,  that  influence, 
constrain,  or  direct  the  project,  program,  or  portfolio. 

Estimate.  A quantitative  assessment  of  the  likely  amount  or  outcome.  Usually  applied  to  project  costs,  resources, 
effort,  and  durations  and  is  usually  preceded  by  a modifier  (i.e.,  preliminary,  conceptual,  feasibility,  order-of- 
magnitude,  definitive).  It  should  always  include  some  indication  of  accuracy  (e.g.,  ± x percent).  See  also  budget 
and  cost. 

Estimate  Activity  Durations.  The  process  of  estimating  the  number  of  work  periods  needed  to  complete  individual 
activities  with  estimated  resources. 

Estimate  Activity  Resources.  The  process  of  estimating  the  type  and  quantities  of  material,  human  resources, 
equipment,  or  supplies  required  to  perform  each  activity. 

Estimate  at  Completion  (EAC).  The  expected  total  cost  of  completing  all  work  expressed  as  the  sum  of  the  actual 
cost  to  date  and  the  estimate  to  complete. 

Estimate  Costs.  The  process  of  developing  an  approximation  of  the  monetary  resources  needed  to  complete 
project  activities. 

Estimate  to  Complete  (ETC).  The  expected  cost  to  finish  all  the  remaining  project  work. 

Execute.  Directing,  managing,  performing,  and  accomplishing  the  project  work;  providing  the  deliverables;  and 
providing  work  performance  information. 

Executing  Process  Group.  Those  processes  performed  to  complete  the  work  defined  in  the  project  management 
plan  to  satisfy  the  project  specifications. 

Expected  Monetary  Value  (EMV)  Analysis.  A statistical  technique  that  calculates  the  average  outcome  when 
the  future  includes  scenarios  that  may  or  may  not  happen.  A common  use  of  this  technique  is  within  decision  tree 
analysis. 

Expert  Judgment.  Judgment  provided  based  upon  expertise  in  an  application  area,  knowledge  area,  discipline, 
industry,  etc.,  as  appropriate  for  the  activity  being  performed.  Such  expertise  may  be  provided  by  any  group  or 
person  with  specialized  education,  knowledge,  skill,  experience,  or  training. 
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External  Dependency.  A relationship  between  project  activities  and  non-project  activities. 

Facilitated  Workshops.  An  elicitation  technique  using  focused  sessions  that  bring  key  cross-functional 
stakeholders  together  to  define  product  requirements. 

Failure  Mode  and  Effect  Analysis  (FMEA).  An  analytical  procedure  in  which  each  potential  failure  mode  in 
every  component  of  a product  is  analyzed  to  determine  its  effect  on  the  reliability  of  that  component  and,  by 
itself  or  in  combination  with  other  possible  failure  modes,  on  the  reliability  of  the  product  or  system  and  on  the 
required  function  of  the  component;  or  the  examination  of  a product  (at  the  system  and/or  lower  levels)  for  all 
ways  that  a failure  may  occur.  For  each  potential  failure,  an  estimate  is  made  of  its  effect  on  the  total  system 
and  of  its  impact.  In  addition,  a review  is  undertaken  of  the  action  planned  to  minimize  the  probability  of  failure 
and  to  minimize  its  effects. 

Fallback  Plan.  Fallback  plans  include  an  alternative  set  of  actions  and  tasks  available  in  the  event  that  the  primary 
plan  needs  to  be  abandoned  because  of  issues,  risks,  or  other  causes. 

Fast  Tracking.  A schedule  compression  technique  in  which  activities  or  phases  normally  done  in  sequence  are 
performed  in  parallel  for  at  least  a portion  of  their  duration. 

Fee.  Represents  profit  as  a component  of  compensation  to  a seller. 

Finish  Date.  A point  in  time  associated  with  a schedule  activity’s  completion.  Usually  qualified  by  one  of  the 
following:  actual,  planned,  estimated,  scheduled,  early,  late,  baseline,  target,  or  current. 

Finish-to-Finish  (FF).  A logical  relationship  in  which  a successor  activity  cannot  finish  until  a predecessor 
activity  has  finished. 

Finish-to-Start  (FS).  A logical  relationship  in  which  a successor  activity  cannot  start  until  a predecessor 
activity  has  finished. 

Firm-Fixed-Price  Contract  (FFP).  A type  of  fixed  price  contract  where  the  buyer  pays  the  seller  a set  amount 
(as  defined  by  the  contract),  regardless  of  the  seller’s  costs. 

Fishbone  diagram.  See  Cause  and  Effect  Diagram. 

Fixed  Formula  Method.  An  earned  value  method  for  assigning  a specified  percentage  of  budget  value  for  a 
work  package  to  the  start  milestone  of  the  work  package  with  the  remaining  budget  value  percentage  assigned 
when  the  work  package  is  complete. 
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Fixed  Price  Incentive  Fee  Contract  (FPIF).  A type  of  contract  where  the  buyer  pays  the  seller  a set  amount  (as 
defined  by  the  contract),  and  the  seller  can  earn  an  additional  amount  if  the  seller  meets  defined  performance 
criteria. 

Fixed  Price  with  Economic  Price  Adjustment  Contracts  (FP-EPA).  A fixed-price  contract,  but  with  a special 
provision  allowing  for  predefined  final  adjustments  to  the  contract  price  due  to  changed  conditions,  such  as  inflation 
changes,  or  cost  increases  (or  decreases)  for  specific  commodities. 

Fixed-Price  Contracts.  An  agreement  that  sets  the  fee  that  will  be  paid  for  a defined  scope  of  work  regardless  of 
the  cost  or  effort  to  deliver  it. 

Float.  Also  called  slack.  See  total  float  and  free  float. 

Flowchart.  The  depiction  in  a diagram  format  of  the  inputs,  process  actions,  and  outputs  of  one  or  more  processes 
within  a system. 

Focus  Groups.  An  elicitation  technique  that  brings  together  prequalified  stakeholders  and  subject  matter  experts 
to  learn  about  their  expectations  and  attitudes  about  a proposed  product,  service,  or  result. 

Forecast.  An  estimate  or  prediction  of  conditions  and  events  in  the  project’s  future  based  on  information  and 
knowledge  available  at  the  time  of  the  forecast.  The  information  is  based  on  the  project’s  past  performance  and 
expected  future  performance,  and  includes  information  that  could  impact  the  project  in  the  future,  such  as  estimate 
at  completion  and  estimate  to  complete. 

Forward  Pass.  A critical  path  method  technique  for  calculating  the  early  start  and  early  finish  dates  by  working 
forward  through  the  schedule  model  from  the  project  start  date  or  a given  point  in  time. 

Free  Float.  The  amount  of  time  that  a schedule  activity  can  be  delayed  without  delaying  the  early  start  date  of  any 
successor  or  violating  a schedule  constraint. 

Functional  Manager.  Someone  with  management  authority  over  an  organizational  unit  within  a functional 
organization.  The  manager  of  any  group  that  actually  makes  a product  or  performs  a service.  Sometimes  called  a 
line  manager. 

Functional  Organization.  A hierarchical  organization  where  each  employee  has  one  clear  superior,  and  staff  are 
grouped  by  areas  of  specialization  and  managed  by  a person  with  expertise  in  that  area. 


©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMB0Ke‘  Guide)  - Fifth  Edition 


541 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


GLOSSARY 


Funding  Limit  Reconciliation.  The  process  of  comparing  the  planned  expenditure  of  project  funds  against  any 
limits  on  the  commitment  of  funds  for  the  project  to  identify  any  variances  between  the  funding  limits  and  the 
planned  expenditures. 

Gantt  Chart.  A bar  chart  of  schedule  information  where  activities  are  listed  on  the  vertical  axis,  dates  are 
shown  on  the  horizontal  axis,  and  activity  durations  are  shown  as  horizontal  bars  placed  according  to  start  and 
finish  dates. 

Grade.  A category  or  rank  used  to  distinguish  items  that  have  the  same  functional  use  (e.g.,  “hammer”)  but  do 
not  share  the  same  requirements  for  quality  (e.g.,  different  hammers  may  need  to  withstand  different  amounts  of 
force). 

Ground  Rules.  Expectations  regarding  acceptable  behavior  by  project  team  members. 

Group  Creativity  Techniques.  Techniques  that  are  used  to  generate  ideas  within  a group  of  stakeholders. 

Group  Decision-Making  Techniques.  Techniques  to  assess  multiple  alternatives  that  will  be  used  to  generate, 
classify,  and  prioritize  product  requirements. 

Guideline.  An  official  recommendation  or  advice  that  indicates  policies,  standards,  or  procedures  for  how 
something  should  be  accomplished. 

Hammock  Activity.  See  summary  activity. 

Hard  Logic.  See  mandatory  dependency. 

Histogram.  A special  form  of  bar  chart  used  to  describe  the  central  tendency,  dispersion,  and  shape  of  a 
statistical  distribution. 

Historical  Information.  Documents  and  data  on  prior  projects  including  project  files,  records,  correspondence, 
closed  contracts,  and  closed  projects. 

Human  Resource  Management  Plan.  A component  of  the  project  management  plan  that  describes  how  the 
roles  and  responsibilities,  reporting  relationships,  and  staff  management  will  be  addressed  and  structured. 

Idea/Mind  Mapping.  Technique  used  to  consolidate  ideas  created  through  individual  brainstorming  sessions  into 
a single  map  to  reflect  commonality  and  differences  in  understanding  and  to  generate  new  ideas. 

Identify  Risks.  The  process  of  determining  which  risks  may  affect  the  project  and  documenting  their  characteristics. 
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Identify  Stakeholders.  The  process  of  identifying  the  people,  groups,  or  organizations  that  could  impact  or  be 
impacted  by  a decision,  activity,  or  outcome  of  the  project;  and  analyzing  and  documenting  relevant  information 
regarding  their  interests,  involvement,  interdependencies,  influence,  and  potential  impact  on  project  success. 

Imposed  Date.  A fixed  date  imposed  on  a schedule  activity  or  schedule  milestone,  usually  in  the  form  of  a 
“start  no  earlier  than”  and  “finish  no  later  than”  date. 

Incentive  Fee.  A set  of  financial  incentives  related  to  cost,  schedule,  or  technical  performance  of  the  seller. 

Incremental  Life  Cycle.  A project  life  cycle  where  the  project  scope  is  generally  determined  early  in  the  project 
life  cycle,  but  time  and  cost  estimates  are  routinely  modified  as  the  project  team’s  understanding  of  the  product 
increases.  Iterations  develop  the  product  through  a series  of  repeated  cycles,  while  increments  successively  add  to 
the  functionality  of  the  product. 

Independent  Estimates.  A process  of  using  a third  party  to  obtain  and  analyze  information  to  support  prediction 
of  cost,  schedule,  or  other  items. 

Influence  Diagram.  A graphical  representation  of  situations  showing  causal  influences,  time  ordering  of  events, 
and  other  relationships  among  variables  and  outcomes. 

Information  Gathering  Techniques.  Repeatable  processes  used  to  assemble  and  organize  data  across  a spectrum 
of  sources. 

Information  Management  Systems.  Facilities,  processes,  and  procedures  used  to  collect,  store,  and  distribute 
information  between  producers  and  consumers  of  information  in  physical  or  electronic  format. 

Initiating  Process  Group.  Those  processes  performed  to  define  a new  project  or  a new  phase  of  an  existing  project 
by  obtaining  authorization  to  start  the  project  or  phase. 

Input.  Any  item,  whether  internal  or  external  to  the  project  that  is  required  by  a process  before  that  process 
proceeds.  May  be  an  output  from  a predecessor  process. 

Inspection.  Examining  or  measuring  to  verify  whether  an  activity,  component,  product,  result,  or  service  conforms 
to  specified  requirements. 

Inspections  and  Audits.  A process  to  observe  performance  of  contracted  work  or  a promised  product  against 
agreed-upon  requirements. 
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Interpersonal  Skills.  Ability  to  establish  and  maintain  relationships  with  other  people. 

Interrelationship  Digraphs.  A quality  management  planning  tool,  the  interrelationship  digraphs  provide  a 
process  for  creative  problem-solving  in  moderately  complex  scenarios  that  possess  intertwined  logical 
relationships. 

Interviews.  A formal  or  informal  approach  to  elicit  information  from  stakeholders  by  talking  to  them  directly. 

Invitation  for  Bid  (IFB).  Generally,  this  term  is  equivalent  to  request  for  proposal.  However,  in  some  application 
areas,  it  may  have  a narrower  or  more  specific  meaning. 

Issue.  A point  or  matter  in  question  or  in  dispute,  or  a point  or  matter  that  is  not  settled  and  is  under  discussion  or 
over  which  there  are  opposing  views  or  disagreements. 

Issue  Log.  A project  document  used  to  document  and  monitor  elements  under  discussion  or  in  dispute  between 
project  stakeholders. 

Iterative  Life  Cycle.  A project  life  cycle  where  the  project  scope  is  generally  determined  early  in  the  project  life 
cycle,  but  time  and  cost  estimates  are  routinely  modified  as  the  project  team’s  understanding  of  the  product 
increases.  Iterations  develop  the  product  through  a series  of  repeated  cycles,  while  increments  successively  add  to 
the  functionality  of  the  product. 

Lag.  The  amount  of  time  whereby  a successor  activity  is  required  to  be  delayed  with  respect  to  a predecessor 
activity. 

Late  Finish  Date  (LF).  In  the  critical  path  method,  the  latest  possible  point  in  time  when  the  uncompleted  portions 
of  a schedule  activity  can  finish  based  on  the  schedule  network  logic,  the  project  completion  date,  and  any  schedule 
constraints. 

Late  Start  Date  (LS).  In  the  critical  path  method,  the  latest  possible  point  in  time  when  the  uncompleted  portions 
of  a schedule  activity  can  start  based  on  the  schedule  network  logic,  the  project  completion  date,  and  any  schedule 
constraints. 

Lead.  The  amount  of  time  whereby  a successor  activity  can  be  advanced  with  respect  to  a predecessor  activity. 

Lessons  Learned.  The  knowledge  gained  during  a project  which  shows  how  project  events  were  addressed  or 
should  be  addressed  in  the  future  with  the  purpose  of  improving  future  performance. 

Lessons  Learned  Knowledge  Base.  A store  of  historical  information  and  lessons  learned  about  both  the  outcomes 
of  previous  project  selection  decisions  and  previous  project  performance. 
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Level  of  Effort  (LOE).  An  activity  that  does  not  produce  definitive  end  products  and  is  measured  by  the  passage 
of  time.  [Note:  Level  of  effort  is  one  of  three  earned  valued  management  (EVM)  types  of  activities  used  to  measure 
work  performance.] 

Leveling.  See  resource  leveling. 

Life  Cycle.  See  project  life  cycle. 

Log.  A document  used  to  record  and  describe  or  denote  selected  items  identified  during  execution  of  a process  or 
activity.  Usually  used  with  a modifier,  such  as  issue,  quality  control,  action,  or  defect. 

Logical  Relationship.  A dependency  between  two  activities,  or  between  an  activity  and  a milestone. 

Majority.  Support  from  more  than  50  percent  of  the  members  of  the  group. 

Make-or-Buy  Analysis.  The  process  of  gathering  and  organizing  data  about  product  requirements  and  analyzing 
them  against  available  alternatives  including  the  purchase  or  internal  manufacture  of  the  product. 

Make-or-Buy  Decisions.  Decisions  made  regarding  the  external  purchase  or  internal  manufacture  of  a product. 

Manage  Communications.  The  process  of  creating,  collecting,  distributing,  storing,  retrieving,  and  the  ultimate 
disposition  of  project  information  in  accordance  with  the  communications  management  plan. 

Manage  Project  Team.  The  process  of  tracking  team  member  performance,  providing  feedback,  resolving  issues, 
and  managing  team  changes  to  optimize  project  performance. 

Manage  Stakeholder  Engagement.  The  process  of  communicating  and  working  with  stakeholders  to  meet  their 
needs/expectations,  address  issues  as  they  occur,  and  foster  appropriate  stakeholder  engagement  in  project 
activities  throughout  the  project  life  cycle. 

Management  Reserve.  An  amount  of  the  project  budget  withheld  for  management  control  purposes.  These 
are  budgets  reserved  for  unforeseen  work  that  is  within  scope  of  the  project.  The  management  reserve  is  not 
included  in  the  performance  measurement  baseline  (PMB). 

Management  Skills.  The  ability  to  plan,  organize,  direct,  and  control  individuals  or  groups  of  people  to  achieve 
specific  goals. 

Mandatory  Dependency.  A relationship  that  is  contractually  required  or  inherent  in  the  nature  of  the  work. 
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Market  Research.  The  process  of  gathering  information  at  conferences,  online  reviews,  and  a variety  of  sources 
to  identify  market  capabilities. 

Master  Schedule.  A summary-level  project  schedule  that  identifies  the  major  deliverables  and  work  breakdown 
structure  components  and  key  schedule  milestones.  See  also  milestone  schedule. 

Material.  The  aggregate  of  things  used  by  an  organization  in  any  undertaking,  such  as  equipment,  apparatus,  tools, 
machinery,  gear,  material,  and  supplies. 

Matrix  Diagrams.  A quality  management  and  control  tool  used  to  perform  data  analysis  within  the  organizational 
structure  created  in  the  matrix.  The  matrix  diagram  seeks  to  show  the  strength  of  relationships  between  factors, 
causes,  and  objectives  that  exist  between  the  rows  and  columns  that  form  the  matrix. 

Matrix  Organization.  Any  organizational  structure  in  which  the  project  manager  shares  responsibility  with  the 
functional  managers  for  assigning  priorities  and  for  directing  the  work  of  persons  assigned  to  the  project. 

Methodology.  A system  of  practices,  techniques,  procedures,  and  rules  used  by  those  who  work  in  a discipline. 

Milestone.  A significant  point  or  event  in  a project,  program,  or  portfolio. 

Milestone  List.  A list  identifying  all  project  milestones  and  normally  indicates  whether  the  milestone  is  mandatory 
or  optional. 

Milestone  Schedule.  A summary-level  schedule  that  identifies  the  major  schedule  milestones.  See  also  master 
schedule. 

Monitor.  Collect  project  performance  data  with  respect  to  a plan,  produce  performance  measures,  and  report  and 
disseminate  performance  information. 

Monitor  and  Control  Project  Work.  The  process  of  tracking,  reviewing,  and  reporting  the  progress  to  meet  the 
performance  objectives  defined  in  the  project  management  plan. 

Monitoring  and  Controlling  Process  Group.  Those  processes  required  to  track,  review,  and  regulate  the  progress 
and  performance  of  the  project;  identify  any  areas  in  which  changes  to  the  plan  are  required;  and  initiate  the 
corresponding  changes. 
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Monte  Carlo  Simulation.  A process  which  generates  hundreds  or  thousands  of  probable  performance  outcomes 
based  on  probability  distributions  for  cost  and  schedule  on  individual  tasks.  The  outcomes  are  then  used  to  generate 
a probability  distribution  for  the  project  as  a whole. 

Most  Likely  Duration.  An  estimate  of  the  most  probable  activity  duration  that  takes  into  account  all  of  the  known 
variables  that  could  affect  performance. 

Multi-Criteria  Decision  Analysis.  This  technique  utilizes  a decision  matrix  to  provide  a systematic  analytical 
approach  for  establishing  criteria,  such  as  risk  levels,  uncertainty,  and  valuation,  to  evaluate  and  rank  many  ideas. 

Near-Critical  Activity.  A schedule  activity  that  has  low  total  float.  The  concept  of  near-critical  is  equally  applicable 
to  a schedule  activity  or  schedule  network  path.  The  limit  below  which  total  float  is  considered  near  critical  is 
subject  to  expert  judgment  and  varies  from  project  to  project. 

Negotiated  Settlements.  The  process  of  reaching  final  equitable  settlement  of  all  outstanding  issues,  claims,  and 
disputes  through  negotiation. 

Negotiation.  The  process  and  activities  to  resolving  disputes  through  consultations  between  involved  parties. 
Network.  See  project  schedule  network  diagram. 

Network  Analysis.  See  schedule  network  analysis. 

Network  Logic.  The  collection  of  schedule  activity  dependencies  that  makes  up  a project  schedule  network 
diagram. 

Network  Path.  Any  continuous  series  of  schedule  activities  connected  with  logical  relationships  in  a project 
schedule  network  diagram. 

Networking.  Establishing  connections  and  relationships  with  other  people  from  the  same  or  other  organizations. 

Node.  One  of  the  defining  points  of  a schedule  network;  a junction  point  joined  to  some  or  all  of  the  other  dependency 
lines. 

Nominal  Group  Technique.  A technique  that  enhances  brainstorming  with  a voting  process  used  to  rank  the 
most  useful  ideas  for  further  brainstorming  or  for  prioritization. 
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Nonconformance  Work.  In  the  cost  of  quality  framework,  nonconformance  work  is  done  to  deal  with  the 
consequences  of  errors  and  failures  in  doing  activities  correctly  on  the  first  attempt.  In  efficient  quality  management 
systems,  the  amount  of  nonconformance  work  will  approach  zero. 

Objective.  Something  toward  which  work  is  to  be  directed,  a strategic  position  to  be  attained,  a purpose  to  be 
achieved,  a result  to  be  obtained,  a product  to  be  produced,  or  a service  to  be  performed. 

Observations.  A technique  that  provides  a direct  way  of  viewing  individuals  in  their  environment  performing  their 
jobs  or  tasks  and  carrying  out  processes. 

Opportunity.  A risk  that  would  have  a positive  effect  on  one  or  more  project  objectives. 

Optimistic  Duration.  An  estimate  of  the  shortest  activity  duration  that  takes  into  account  all  of  the  known 
variables  that  could  affect  performance. 

Organizational  Breakdown  Structure  (OBS).  A hierarchical  representation  of  the  project  organization  that 
illustrates  the  relationship  between  project  activities  and  the  organizational  units  that  will  perform  those  activities. 

Organizational  Process  Assets.  Plans,  processes,  policies,  procedures,  and  knowledge  bases  that  are  specific  to 
and  used  by  the  performing  organization. 

Organizational  Project  Management  Maturity.  The  level  of  an  organization’s  ability  to  deliver  the  desired  strategic 
outcomes  in  a predictable,  controllable,  and  reliable  manner. 

Output.  A product,  result,  or  service  generated  by  a process.  May  be  an  input  to  a successor  process. 

Parametric  Estimating.  An  estimating  technique  in  which  an  algorithm  is  used  to  calculate  cost  or  duration 
based  on  historical  data  and  project  parameters. 

Pareto  Diagram.  A histogram,  ordered  by  frequency  of  occurrence,  that  shows  how  many  results  were 
generated  by  each  identified  cause. 

Path  Convergence.  A relationship  in  which  a schedule  activity  has  more  than  one  predecessor. 

Path  Divergence.  A relationship  in  which  a schedule  activity  has  more  than  one  successor. 

Payment  Systems.  The  system  used  to  provide  and  track  supplier’s  invoices  and  payments  for  services  and 
products. 
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Percent  Complete.  An  estimate  expressed  as  a percent  of  the  amount  of  work  that  has  been  completed  on  an 
activity  or  a work  breakdown  structure  component. 

Perform  Integrated  Change  Control.  The  process  of  reviewing  all  change  requests;  approving  changes 
and  managing  changes  to  deliverables,  organizational  process  assets,  project  documents,  and  the  project 
management  plan;  and  communicating  their  disposition. 

Perform  Qualitative  Risk  Analysis.  The  process  of  prioritizing  risks  for  further  analysis  or  action  by  assessing  and 
combining  their  probability  of  occurrence  and  impact. 

Perform  Quality  Assurance.  The  process  of  auditing  the  quality  requirements  and  the  results  from  quality  control 
measurements  to  ensure  that  appropriate  quality  standards  and  operational  definitions  are  used. 

Perform  Quantitative  Risk  Analysis.  The  process  of  numerically  analyzing  the  effect  of  identified  risks  on  overall 
project  objectives. 

Performance  Measurement  Baseline.  An  approved,  integrated  scope-schedule-cost  plan  for  the  project  work 
against  which  project  execution  is  compared  to  measure  and  manage  performance.  The  PMB  includes  contingency 
reserve,  but  excludes  management  reserve. 

Performance  Reporting.  See  work  performance  reports. 

Performance  Reports.  See  work  performance  reports. 

Performance  Reviews.  A technique  that  is  used  to  measure,  compare,  and  analyze  actual  performance  of 
work  in  progress  on  the  project  against  the  baseline. 

Performing  Organization.  An  enterprise  whose  personnel  are  most  directly  involved  in  doing  the  work  of  the 
project  or  program. 

Pessimistic  Duration.  Estimate  of  the  longest  activity  duration  that  takes  into  account  all  of  the  known  variables 
that  could  affect  performance. 

Phase.  See  project  phase. 

Phase  Gate.  A review  at  the  end  of  a phase  in  which  a decision  is  made  to  continue  to  the  next  phase,  to 
continue  with  modification,  or  to  end  a project  or  program. 

Plan  Communications  Management.  The  process  of  developing  an  appropriate  approach  and  plan  for  project 
communications  based  on  stakeholder’s  information  needs  and  requirements  and  available  organizational  assets. 
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Plan  Cost  Management.  The  process  that  establishes  the  policies,  procedures,  and  documentation  for  planning, 
managing,  expending,  and  controlling  project  costs. 

Plan  Human  Resource  Management.  The  process  of  identifying  and  documenting  project  roles,  responsibilities, 
required  skills,  reporting  relationships,  and  creating  a staffing  management  plan. 

Plan  Procurement  Management.  The  process  of  documenting  project  procurement  decisions,  specifying  the 
approach,  and  identifying  potential  sellers. 

Plan  Quality  Management.  The  process  of  identifying  quality  requirements  and/or  standards  for  the  project  and  its 
deliverables,  and  documenting  how  the  project  will  demonstrate  compliance  with  quality  requirements. 

Plan  Risk  Management.  The  process  of  defining  how  to  conduct  risk  management  activities  for  a project. 

Plan  Risk  Responses.  The  process  of  developing  options  and  actions  to  enhance  opportunities  and  to  reduce 
threats  to  project  objectives. 

Plan  Schedule  Management.  The  process  of  establishing  the  policies,  procedures,  and  documentation  for 
planning,  developing,  managing,  executing,  and  controlling  the  project  schedule. 

Plan  Scope  Management.  The  process  of  creating  a scope  management  plan  that  documents  how  the  project 
scope  will  be  defined,  validated,  and  controlled. 

Plan  Stakeholder  Management.  The  process  of  developing  appropriate  management  strategies  to  effectively 
engage  stakeholders  throughout  the  project  life  cycle,  based  on  the  analysis  of  their  needs,  interests,  and  potential 
impact  on  project  success. 

Planned  Value  (PV).  The  authorized  budget  assigned  to  scheduled  work. 

Planning  Package.  A work  breakdown  structure  component  below  the  control  account  with  known  work 
content  but  without  detailed  schedule  activities.  See  also  control  account. 

Planning  Process  Group.  Those  processes  required  to  establish  the  scope  of  the  project,  refine  the  objectives,  and 
define  the  course  of  action  required  to  attain  the  objectives  that  the  project  was  undertaken  to  achieve. 

Plurality.  Decisions  made  by  the  largest  block  in  a group,  even  if  a majority  is  not  achieved. 

Policy.  A structured  pattern  of  actions  adopted  by  an  organization  such  that  the  organization’s  policy  can  be 
explained  as  a set  of  basic  principles  that  govern  the  organization’s  conduct. 
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Portfolio.  Projects,  programs,  subportfolios,  and  operations  managed  as  a group  to  achieve  strategic  objectives. 

Portfolio  Management.  The  centralized  management  of  one  or  more  portfolios  to  achieve  strategic  objectives. 

Practice.  A specific  type  of  professional  or  management  activity  that  contributes  to  the  execution  of  a process 
and  that  may  employ  one  or  more  techniques  and  tools. 

Precedence  Diagramming  Method  (PDM).  A technique  used  for  constructing  a schedule  model  in  which 
activities  are  represented  by  nodes  and  are  graphically  linked  by  one  or  more  logical  relationships  to  show  the 
sequence  in  which  the  activities  are  to  be  performed. 

Precedence  Relationship. The  term  used  in  the  precedence  diagramming  method  for  a logical  relationship.  In  current 
usage,  however,  precedence  relationship,  logical  relationship,  and  dependency  are  widely  used  interchangeably, 
regardless  of  the  diagramming  method  used.  See  also  logical  relationship. 

Precision.  Within  the  quality  management  system,  precision  is  a measure  of  exactness. 

Predecessor  Activity.  An  activity  that  logically  comes  before  a dependent  activity  in  a schedule. 

Predictive  Life  Cycle.  A form  of  project  life  cycle  in  which  the  project  scope,  and  the  time  and  cost  required  to 
deliver  that  scope,  are  determined  as  early  in  the  life  cycle  as  possible. 

Preferential  Logic.  See  discretionary  dependency. 

Preferred  Logic.  See  discretionary  dependency. 

Preventive  Action.  An  intentional  activity  that  ensures  the  future  performance  of  the  project  work  is  aligned 
with  the  project  management  plan. 

Prioritization  Matrices.  A quality  management  planning  tool  used  to  identify  key  issues  and  evaluate  suitable 
alternatives  to  define  a set  of  implementation  priorities. 

Probability  and  Impact  Matrix.  A grid  for  mapping  the  probability  of  each  risk  occurrence  and  its  impact  on 
project  objectives  if  that  risk  occurs. 

Procedure.  An  established  method  of  accomplishing  a consistent  performance  or  result,  a procedure  typically 
can  be  described  as  the  sequence  of  steps  that  will  be  used  to  execute  a process. 

Process.  A systematic  series  of  activities  directed  towards  causing  an  end  result  such  that  one  or  more  inputs 
will  be  acted  upon  to  create  one  or  more  outputs. 
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Process  Analysis.  A process  analysis  follows  the  steps  outlined  in  the  process  improvement  plan  to  identify 
needed  improvements. 

Process  Decision  Program  Charts  (PDPC).  The  PDPC  is  used  to  understand  a goal  in  relation  to  the  steps  for 
getting  to  the  goal. 

Process  Improvement  Plan.  A subsidiary  plan  of  the  project  management  plan.  It  details  the  steps  for  analyzing 
processes  to  identify  activities  that  enhance  their  value. 

Procurement  Audits.  The  review  of  contracts  and  contracting  processes  for  completeness,  accuracy,  and 
effectiveness. 

Procurement  Documents.  The  documents  utilized  in  bid  and  proposal  activities,  which  include  the  buyer’s 
Invitation  for  Bid,  Invitation  for  Negotiations,  Request  for  Information,  Request  for  Quotation,  Request  for  Proposal, 
and  seller’s  responses. 

Procurement  Management  Plan.  A component  of  the  project  or  program  management  plan  that  describes 
how  a project  team  will  acquire  goods  and  services  from  outside  the  performing  organization. 

Procurement  Performance  Reviews.  A structured  review  of  the  seller’s  progress  to  deliver  project  scope  and 
quality,  within  cost  and  on  schedule,  as  compared  to  the  contract. 

Procurement  Statement  of  Work.  Describes  the  procurement  item  in  sufficient  detail  to  allow  prospective  sellers 
to  determine  if  they  are  capable  of  providing  the  products,  services,  or  results. 

Product.  An  artifact  that  is  produced,  is  quantifiable,  and  can  be  either  an  end  item  in  itself  or  a component  item. 
Additional  words  for  products  are  material  and  goods.  Contrast  with  result.  See  also  deliverable. 

Product  Analysis.  For  projects  that  have  a product  as  a deliverable,  it  is  a tool  to  define  scope  that  generally  means 
asking  questions  about  a product  and  forming  answers  to  describe  the  use,  characteristics,  and  other  the  relevant 
aspects  of  what  is  going  to  be  manufactured. 

Product  Life  Cycle.  The  series  of  phases  that  represent  the  evolution  of  a product,  from  concept  through  delivery, 
growth,  maturity,  and  to  retirement. 

Product  Scope.  The  features  and  functions  that  characterize  a product,  service,  or  result. 

Product  Scope  Description.  The  documented  narrative  description  of  the  product  scope. 
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Program.  A group  of  related  projects,  subprograms,  and  program  activities  managed  in  a coordinated  way  to 
obtain  benefits  not  available  from  managing  them  individually. 

Program  Evaluation  and  Review  Technique  (PERT).  A technique  for  estimating  that  applies  a weighted 
average  of  optimistic,  pessimistic,  and  most  likely  estimates  when  there  is  uncertainty  with  the  individual  activity 
estimates. 

Program  Management.  The  application  of  knowledge,  skills,  tools,  and  techniques  to  a program  to  meet  the 
program  requirements  and  to  obtain  benefits  and  control  not  available  by  managing  projects  individually. 

Progressive  Elaboration.  The  iterative  process  of  increasing  the  level  of  detail  in  a project  management  plan  as 
greater  amounts  of  information  and  more  accurate  estimates  become  available. 

Project.  A temporary  endeavor  undertaken  to  create  a unique  product,  service,  or  result. 

Project-Based  Organizations  (PBOs).  A variety  of  organizational  forms  that  involve  the  creation  of  temporary 
systems  for  the  performance  of  projects.  PBOs  conduct  the  majority  of  their  activities  as  projects  and/or  provide 
project  over  functional  approaches. 

Project  Calendar.  A calendar  that  identifies  working  days  and  shifts  that  are  available  for  scheduled  activities. 

Project  Charter.  A document  issued  by  the  project  initiator  or  sponsor  that  formally  authorizes  the  existence 
of  a project  and  provides  the  project  manager  with  the  authority  to  apply  organizational  resources  to  project 
activities. 

Project  Communications  Management.  Project  Communications  Management  includes  the  processes  that 
are  required  to  ensure  timely  and  appropriate  planning,  collection,  creation,  distribution,  storage,  retrieval, 
management,  control,  monitoring,  and  the  ultimate  disposition  of  project  information. 

Project  Cost  Management.  Project  Cost  Management  includes  the  processes  involved  in  planning,  estimating, 
budgeting,  financing,  funding,  managing,  and  controlling  costs  so  that  the  project  can  be  completed  within  the 
approved  budget. 

Project  Funding  Requirements.  Forecast  project  costs  to  be  paid  that  are  derived  from  the  cost  baseline  for  total 
or  periodic  requirements,  including  projected  expenditures  plus  anticipated  liabilities. 

Project  Governance.  The  alignment  of  project  objectives  with  the  strategy  of  the  larger  organization  by  the 
project  sponsor  and  project  team.  A project’s  governance  is  defined  by  and  is  required  to  fit  within  the  larger 
context  of  the  program  or  organization  sponsoring  it,  but  is  separate  from  organizational  governance. 
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Project  Human  Resource  Management.  Project  Human  Resource  Management  includes  the  processes  that 
organize,  manage,  and  lead  the  project  team. 

Project  Initiation.  Launching  a process  that  can  result  in  the  authorization  of  a new  project. 

Project  Integration  Management.  Project  Integration  Management  includes  the  processes  and  activities  needed 
to  identify,  define,  combine,  unify,  and  coordinate  the  various  processes  and  project  management  activities  within 
the  Project  Management  Process  Groups. 

Project  Life  Cycle.  The  series  of  phases  that  a project  passes  through  from  its  initiation  to  its  closure. 

Project  Management.  The  application  of  knowledge,  skills,  tools,  and  techniques  to  project  activities  to  meet  the 
project  requirements. 

Project  Management  Body  of  Knowledge.  An  inclusive  term  that  describes  the  sum  of  knowledge  within 
the  profession  of  project  management.  As  with  other  professions,  such  as  law,  medicine,  and  accounting,  the 
body  of  knowledge  rests  with  the  practitioners  and  academics  that  apply  and  advance  it.  The  complete  project 
management  body  of  knowledge  includes  proven  traditional  practices  that  are  widely  applied  and  innovative 
practices  that  are  emerging  in  the  profession.  The  body  of  knowledge  includes  both  published  and  unpublished 
materials.  This  body  of  knowledge  is  constantly  evolving.  PMI’s  F/WSOK®  Guide  identifies  a subset  of  the  project 
management  body  of  knowledge  that  is  generally  recognized  as  good  practice. 

Project  Management  Information  System.  An  information  system  consisting  of  the  tools  and  techniques  used  to 
gather,  integrate,  and  disseminate  the  outputs  of  project  management  processes.  It  is  used  to  support  all  aspects 
of  the  project  from  initiating  through  closing,  and  can  include  both  manual  and  automated  systems. 

Project  Management  Knowledge  Area.  An  identified  area  of  project  management  defined  by  its  knowledge 
requirements  and  described  in  terms  of  its  component  processes,  practices,  inputs,  outputs,  tools,  and  techniques. 

Project  Management  Office  (PMO).  An  organizational  structure  that  standardizes  the  project-related  governance 
processes  and  facilitates  the  sharing  of  resources,  methodologies,  tools,  and  techniques. 

Project  Management  Plan.  The  document  that  describes  how  the  project  will  be  executed  monitored,  and 
controlled. 

Project  Management  Process  Group.  A logical  grouping  of  project  management  inputs,  tools  and  techniques, 
and  outputs.  The  Project  Management  Process  Groups  include  initiating  processes,  planning  processes,  executing 
processes,  monitoring  and  controlling  processes,  and  closing  processes.  Project  Management  Process  Groups  are 
not  project  phases. 
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Project  Management  Staff.  The  members  of  the  project  team  who  perform  project  management  activities  such  as 
schedule,  communications,  risk  management,  etc. 

Project  Management  System.  The  aggregation  of  the  processes,  tools,  techniques,  methodologies,  resources,  and 
procedures  to  manage  a project. 

Project  Management  Team.  The  members  of  the  project  team  who  are  directly  involved  in  project  management 
activities.  On  some  smaller  projects,  the  project  management  team  may  include  virtually  all  of  the  project  team 
members. 

Project  Manager  (PM).  The  person  assigned  by  the  performing  organization  to  lead  the  team  that  is  responsible 
for  achieving  the  project  objectives. 

Project  Organization  Chart.  A document  that  graphically  depicts  the  project  team  members  and  their 
interrelationships  for  a specific  project. 

Project  Phase.  A collection  of  logically  related  project  activities  that  culminates  in  the  completion  of  one  or 
more  deliverables. 

Project  Procurement  Management.  Project  Procurement  Management  includes  the  processes  necessary  to 
purchase  or  acquire  products,  services,  or  results  needed  from  outside  the  project  team. 

Project  Quality  Management.  Project  Quality  Management  includes  the  processes  and  activities  of  the  performing 
organization  that  determine  quality  policies,  objectives,  and  responsibilities  so  that  the  project  will  satisfy  the  needs 
for  which  it  was  undertaken. 

Project  Risk  Management.  Project  Risk  Management  includes  the  processes  of  conducting  risk  management 
planning,  identification,  analysis,  response  planning,  and  controlling  risk  on  a project. 

Project  Schedule.  An  output  of  a schedule  model  that  presents  linked  activities  with  planned  dates,  durations, 
milestones,  and  resources. 

Project  Schedule  Network  Diagram.  A graphical  representation  of  the  logical  relationships  among  the  project 
schedule  activities. 

Project  Scope.  The  work  performed  to  deliver  a product,  service,  or  result  with  the  specified  features  and  functions. 

Project  Scope  Management.  Project  Scope  Management  includes  the  processes  required  to  ensure  that  the 
project  includes  all  the  work  required,  and  only  the  work  required,  to  complete  the  project  successfully. 
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Project  Scope  Statement.  The  description  of  the  project  scope,  major  deliverables,  assumptions,  and  constraints. 

Project  Stakeholder  Management.  Project  Stakeholder  Management  includes  the  processes  required  to  identify 
all  people  or  organizations  impacted  by  the  project,  analyzing  stakeholder  expectations  and  impact  on  the  project, 
and  developing  appropriate  management  strategies  for  effectively  engaging  stakeholders  in  project  decisions  and 
execution. 

Project  Statement  of  Work.  See  statement  of  work. 

Project  Team.  A set  of  individuals  who  support  the  project  manager  in  performing  the  work  of  the  project  to 
achieve  its  objectives. 

Project  Team  Directory.  A documented  list  of  project  team  members,  their  project  roles,  and  communication 
information. 

Project  Time  Management.  Project  Time  Management  includes  the  processes  required  to  manage  the  timely 
completion  of  the  project. 

Projectized  Organization.  Any  organizational  structure  in  which  the  project  manager  has  full  authority  to  assign 
priorities,  apply  resources,  and  direct  the  work  of  persons  assigned  to  the  project. 

Proposal  Evaluation  Techniques.  The  process  of  reviewing  proposals  provided  by  suppliers  to  support  contract 
award  decisions. 

Prototypes.  A method  of  obtaining  early  feedback  on  requirements  by  providing  a working  model  of  the  expected 
product  before  actually  building  it. 

Quality.  The  degree  to  which  a set  of  inherent  characteristics  fulfills  requirements. 

Quality  Audits.  A quality  audit  is  a structured,  independent  process  to  determine  if  project  activities  comply 
with  organizational  and  project  policies,  processes,  and  procedures. 

Quality  Checklists.  A structured  tool  used  to  verify  that  a set  of  required  steps  has  been  performed. 

Quality  Control  Measurements.  The  documented  results  of  control  quality  activities. 

Quality  Function  Deployment  (QFD).  A facilitated  workshop  technique  that  helps  to  determine  critical 
characteristics  for  new  product  development. 

Quality  Management  and  Control  Tools.  They  are  a type  of  quality  planning  tools  used  to  link  and  sequence  the 
activities  identified. 
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Quality  Management  Plan.  A component  of  the  project  or  program  management  plan  that  describes  how  an 
organization’s  quality  policies  will  be  implemented. 

Quality  Management  System.  The  organizational  framework  whose  structure  provides  the  policies,  processes, 
procedures,  and  resources  required  to  implement  the  quality  management  plan.  The  typical  project  quality 
management  plan  should  be  compatible  to  the  organization’s  quality  management  system. 

Quality  Metrics.  A description  of  a project  or  product  attribute  and  how  to  measure  it. 

Quality  Policy.  A policy  specific  to  the  Project  Quality  Management  Knowledge  Area,  it  establishes  the  basic 
principles  that  should  govern  the  organization’s  actions  as  it  implements  its  system  for  quality  management. 

Quality  Requirement.  A condition  or  capability  that  will  be  used  to  assess  conformance  by  validating  the 
acceptability  of  an  attribute  for  the  quality  of  a result. 

Quantitative  Risk  Analysis  and  Modeling  Techniques.  Commonly  used  techniques  for  both  event-oriented  and 
project-oriented  analysis  approaches. 

Questionnaires  and  Surveys.  Written  sets  of  questions  designed  to  quickly  accumulate  information  from  a large 
number  of  respondents. 

RACI.  A common  type  of  responsibility  assignment  matrix  that  uses  responsible,  accountable,  consult,  and  inform 
statuses  to  define  the  involvement  of  stakeholders  in  project  activities. 

Records  Management  System.  A specific  set  of  processes,  related  control  functions,  and  tools  that  are 
consolidated  and  combined  to  record  and  retain  information  about  the  project. 

Regression  Analysis.  An  analytic  technique  where  a series  of  input  variables  are  examined  in  relation  to  their 
corresponding  output  results  in  order  to  develop  a mathematical  or  statistical  relationship. 

Regulation.  Requirements  imposed  by  a governmental  body.  These  requirements  can  establish  product,  process,  or 
service  characteristics,  including  applicable  administrative  provisions  that  have  government-mandated  compliance. 

Reporting  Systems.  Facilities,  processes,  and  procedures  used  to  generate  or  consolidate  reports  from  one  or 
more  information  management  systems  and  facilitate  report  distribution  to  the  project  stakeholders. 

Request  for  Information  (RFI).  A type  of  procurement  document  whereby  the  buyer  requests  a potential  seller 
to  provide  various  pieces  of  information  related  to  a product  or  service  or  seller  capability. 
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Request  for  Proposal  (RFP).  A type  of  procurement  document  used  to  request  proposals  from  prospective 
sellers  of  products  or  services.  In  some  application  areas,  it  may  have  a narrower  or  more  specific  meaning. 

Request  for  Quotation  (RFQ).  A type  of  procurement  document  used  to  request  price  quotations  from 
prospective  sellers  of  common  or  standard  products  or  services.  Sometimes  used  in  place  of  request  for 
proposal  and,  in  some  application  areas,  it  may  have  a narrower  or  more  specific  meaning. 

Requested  Change.  A formally  documented  change  request  that  is  submitted  for  approval  to  the  integrated 
change  control  process. 

Requirement.  A condition  or  capability  that  is  required  to  be  present  in  a product,  service,  or  result  to  satisfy  a 
contract  or  other  formally  imposed  specification. 

Requirements  Documentation.  A description  of  how  individual  requirements  meet  the  business  need  for  the 
project. 

Requirements  Management  Plan.  A component  of  the  project  or  program  management  plan  that  describes  how 
requirements  will  be  analyzed,  documented,  and  managed. 

Requirements  Traceability  Matrix.  A grid  that  links  product  requirements  from  their  origin  to  the  deliverables 
that  satisfy  them. 

Reserve.  A provision  in  the  project  management  plan  to  mitigate  cost  and/or  schedule  risk.  Often  used  with  a 
modifier  (e.g.,  management  reserve,  contingency  reserve)  to  provide  further  detail  on  what  types  of  risk  are  meant 
to  be  mitigated. 

Reserve  Analysis.  An  analytical  technique  to  determine  the  essential  features  and  relationships  of  components  in 
the  project  management  plan  to  establish  a reserve  for  the  schedule  duration,  budget,  estimated  cost,  or  funds  for 
a project. 

Residual  Risk.  A risk  that  remains  after  risk  responses  have  been  implemented. 

Resource.  Skilled  human  resources  (specific  disciplines  either  individually  or  in  crews  or  teams),  equipment, 
services,  supplies,  commodities,  material,  budgets,  or  funds. 

Resource  Breakdown  Structure.  A hierarchical  representation  of  resources  by  category  and  type. 

Resource  Calendar.  A calendar  that  identifies  the  working  days  and  shifts  on  which  each  specific  resource  is 
available. 
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Resource  Histogram.  A bar  chart  showing  the  amount  of  time  that  a resource  is  scheduled  to  work  over  a series  of 
time  periods.  Resource  availability  may  be  depicted  as  a line  for  comparison  purposes.  Contrasting  bars  may  show 
actual  amounts  of  resources  used  as  the  project  progresses. 

Resource  Leveling.  A technique  in  which  start  and  finish  dates  are  adjusted  based  on  resource  constraints  with 
the  goal  of  balancing  demand  for  resources  with  the  available  supply. 

Resource  Optimization  Techniques.  A technique  that  is  used  to  adjust  the  start  and  finish  dates  of  activities  that 
adjust  planned  resource  use  to  be  equal  to  or  less  than  resource  availability. 

Resource  Smoothing.  A technique  which  adjusts  the  activities  of  a schedule  model  such  that  the  requirement  for 
resources  on  the  project  do  not  exceed  certain  predefined  resource  limits. 

Responsibility.  An  assignment  that  can  be  delegated  within  a project  management  plan  such  that  the  assigned 
resource  incurs  a duty  to  perform  the  requirements  of  the  assignment. 

Responsibility  Assignment  Matrix  (RAM).  A grid  that  shows  the  project  resources  assigned  to  each  work 
package. 

Result.  An  output  from  performing  project  management  processes  and  activities.  Results  include  outcomes 
(e.g.,  integrated  systems,  revised  process,  restructured  organization,  tests,  trained  personnel,  etc.)  and  documents 
(e.g.,  policies,  plans,  studies,  procedures,  specifications,  reports,  etc.).  Contrast  with  product.  See  also  deliverable. 

Rework.  Action  taken  to  bring  a defective  or  nonconforming  component  into  compliance  with  requirements  or 
specifications. 

Risk.  An  uncertain  event  or  condition  that,  if  it  occurs,  has  a positive  or  negative  effect  on  one  or  more  project 
objectives. 

Risk  Acceptance.  A risk  response  strategy  whereby  the  project  team  decides  to  acknowledge  the  risk  and  not 
take  any  action  unless  the  risk  occurs. 

Risk  Appetite.  The  degree  of  uncertainty  an  entity  is  willing  to  take  on,  in  anticipation  of  a reward. 

Risk  Audits.  Examination  and  documentation  of  the  effectiveness  of  risk  responses  in  dealing  with  identified  risks 
and  their  root  causes,  as  well  as  the  effectiveness  of  the  risk  management  process. 

Risk  Avoidance.  A risk  response  strategy  whereby  the  project  team  acts  to  eliminate  the  threat  or  protect  the 
project  from  its  impact. 
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Risk  Breakdown  Structure  (RBS).  A hierarchical  representation  of  risks  according  to  their  risk  categories. 

Risk  Categorization.  Organization  by  sources  of  risk  (e.g.,  using  the  RBS),  the  area  of  the  project  affected  (e.g., 
using  the  WBS),  or  other  useful  category  (e.g.,  project  phase)  to  determine  the  areas  of  the  project  most  exposed 
to  the  effects  of  uncertainty. 

Risk  Category.  A group  of  potential  causes  of  risk. 

Risk  Data  Quality  Assessment.  Technique  to  evaluate  the  degree  to  which  the  data  about  risks  is  useful  for  risk 
management. 

Risk  Management  Plan.  A component  of  the  project,  program,  or  portfolio  management  plan  that  describes  how 
risk  management  activities  will  be  structured  and  performed. 

Risk  Mitigation.  A risk  response  strategy  whereby  the  project  team  acts  to  reduce  the  probability  of  occurrence 
or  impact  of  a risk. 

Risk  Reassessment.  Risk  reassessment  is  the  identification  of  new  risks,  reassessment  of  current  risks,  and  the 
closing  of  risks  that  are  outdated. 

Risk  Register.  A document  in  which  the  results  of  risk  analysis  and  risk  response  planning  are  recorded. 

Risk  Threshold.  Measure  of  the  level  of  uncertainty  or  the  level  of  impact  at  which  a stakeholder  may  have  a 
specific  interest.  Below  that  risk  threshold,  the  organization  will  accept  the  risk.  Above  that  risk  threshold,  the 
organization  will  not  tolerate  the  risk. 

Risk  Tolerance.  The  degree,  amount,  or  volume  of  risk  that  an  organization  or  individual  will  withstand. 

Risk  Transference.  A risk  response  strategy  whereby  the  project  team  shifts  the  impact  of  a threat  to  a third 
party,  together  with  ownership  of  the  response. 

Risk  Urgency  Assessment.  Review  and  determination  of  the  timing  of  actions  that  may  need  to  occur  sooner  than 
other  risk  items. 

Role.  A defined  function  to  be  performed  by  a project  team  member,  such  as  testing,  filing,  inspecting,  or  coding. 

Rolling  Wave  Planning.  An  iterative  planning  technique  in  which  the  work  to  be  accomplished  in  the  near  term 
is  planned  in  detail,  while  the  work  in  the  future  is  planned  at  a higher  level. 


560  ©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKs‘  Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


GLOSSARY 


Root  Cause  Analysis.  An  analytical  technique  used  to  determine  the  basic  underlying  reason  that  causes  a 
variance  or  a defect  or  a risk.  A root  cause  may  underlie  more  than  one  variance  or  defect  or  risk. 

Scatter  Diagram.  A correlation  chart  that  uses  a regression  line  to  explain  or  to  predict  how  the  change  in  an 
independent  variable  will  change  a dependent  variable. 

Schedule.  See  project  schedule  and  see  also  schedule  model. 

Schedule  Baseline.  The  approved  version  of  a schedule  model  that  can  be  changed  only  through  formal  change 
control  procedures  and  is  used  as  a basis  for  comparison  to  actual  results. 

Schedule  Compression.  Techniques  used  to  shorten  the  schedule  duration  without  reducing  the  project  scope. 

Schedule  Data.  The  collection  of  information  for  describing  and  controlling  the  schedule. 

Schedule  Forecasts.  Estimates  or  predictions  of  conditions  and  events  in  the  project’s  future  based  on  information 
and  knowledge  available  at  the  time  the  schedule  is  calculated. 

Schedule  Management  Plan.  A component  of  the  project  management  plan  that  establishes  the  criteria  and  the 
activities  for  developing,  monitoring,  and  controlling  the  schedule. 

Schedule  Model.  A representation  of  the  plan  for  executing  the  project’s  activities  including  durations, 
dependencies,  and  other  planning  information,  used  to  produce  a project  schedule  along  with  other  scheduling 
artifacts. 

Schedule  Network  Analysis.  The  technique  of  identifying  early  and  late  start  dates,  as  well  as  early  and  late  finish 
dates,  for  the  uncompleted  portions  of  project  schedule  activities.  See  also  backward  pass,  critical  path  method, 
critical  chain  method,  and  resource  leveling. 

Schedule  Network  Templates.  A set  of  activities  and  relationships  that  have  been  established  that  can  be  used 
repeatedly  for  a particular  application  area  or  an  aspect  of  the  project  where  a prescribed  sequence  is  desired. 

Schedule  Performance  Index  (SPI).  A measure  of  schedule  efficiency  expressed  as  the  ratio  of  earned  value  to 
planned  value. 

Schedule  Variance  (SV).  A measure  of  schedule  performance  expressed  as  the  difference  between  the  earned 
value  and  the  planned  value. 

Scheduling  Tool.  A tool  that  provides  schedule  component  names,  definitions,  structural  relationships,  and 
formats  that  support  the  application  of  a scheduling  method. 
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Scope.  The  sum  of  the  products,  services,  and  results  to  be  provided  as  a project.  See  also  project  scope  and 
product  scope. 

Scope  Baseline.  The  approved  version  of  a scope  statement,  work  breakdown  structure  (WBS),  and  its  associated 
WBS  dictionary,  that  can  be  changed  only  through  formal  change  control  procedures  and  is  used  as  a basis  for 
comparison. 

Scope  Change.  Any  change  to  the  project  scope.  A scope  change  almost  always  requires  an  adjustment  to  the 
project  cost  or  schedule. 

Scope  Creep.  The  uncontrolled  expansion  to  product  or  project  scope  without  adjustments  to  time,  cost,  and 
resources. 

Scope  Management  Plan.  A component  of  the  project  or  program  management  plan  that  describes  how  the 
scope  will  be  defined,  developed,  monitored,  controlled,  and  verified. 

Secondary  Risk.  A risk  that  arises  as  a direct  result  of  implementing  a risk  response. 

Selected  Sellers.  The  sellers  which  have  been  selected  to  provide  a contracted  set  of  services  or  products. 

Seller.  A provider  or  supplier  of  products,  services,  or  results  to  an  organization. 

Seller  Proposals.  Formal  responses  from  sellers  to  a request  for  proposal  or  other  procurement  document 
specifying  the  price,  commercial  terms  of  sale,  and  technical  specifications  or  capabilities  the  seller  will  do  for  the 
requesting  organization  that,  if  accepted,  would  bind  the  seller  to  perform  the  resulting  agreement. 

Sensitivity  Analysis.  A quantitative  risk  analysis  and  modeling  technique  used  to  help  determine  which  risks  have 
the  most  potential  impact  on  the  project.  It  examines  the  extent  to  which  the  uncertainty  of  each  project  element 
affects  the  objective  being  examined  when  all  other  uncertain  elements  are  held  at  their  baseline  values.  The  typical 
display  of  results  is  in  the  form  of  a tornado  diagram. 

Sequence  Activities.  The  process  of  identifying  and  documenting  relationships  among  the  project  activities. 

Seven  Basic  Quality  Tools.  A standard  toolkit  used  by  quality  management  professionals  who  are  responsible  for 
planning,  monitoring,  and  controlling  the  issues  related  to  quality  in  an  organization. 

Simulation.  A simulation  uses  a project  model  that  translates  the  uncertainties  specified  at  a detailed  level  into 
their  potential  impact  on  objectives  that  are  expressed  at  the  level  of  the  total  project.  Project  simulations  use 
computer  models  and  estimates  of  risk,  usually  expressed  as  a probability  distribution  of  possible  costs  or  durations 
at  a detailed  work  level,  and  are  typically  performed  using  Monte  Carlo  analysis. 
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Soft  Logic.  See  discretionary  dependency. 

Source  Selection  Criteria.  A set  of  attributes  desired  by  the  buyer  which  a seller  is  required  to  meet  or  exceed  to 
be  selected  for  a contract. 

Specification.  A document  that  specifies,  in  a complete,  precise,  verifiable  manner,  the  requirements,  design, 
behavior,  or  other  characteristics  of  a system,  component,  product,  result,  or  service  and  the  procedures  for 
determining  whether  these  provisions  have  been  satisfied.  Examples  are:  requirement  specification,  design 
specification,  product  specification,  and  test  specification. 

Specification  Limits.  The  area,  on  either  side  of  the  centerline,  or  mean,  of  data  plotted  on  a control  chart  that 
meets  the  customer’s  requirements  for  a product  or  service.  This  area  may  be  greater  than  or  less  than  the  area 
defined  by  the  control  limits.  See  also  control  limits. 

Sponsor.  A person  or  group  who  provides  resources  and  support  for  the  project,  program,  or  portfolio  and  is 
accountable  for  enabling  success. 

Sponsoring  Organization.  The  entity  responsible  for  providing  the  project’s  sponsor  and  a conduit  for  project 
funding  or  other  project  resources. 

Staffing  Management  Plan.  A component  of  the  human  resource  plan  that  describes  when  and  how  project 
team  members  will  be  acquired  and  how  long  they  will  be  needed. 

Stakeholder.  An  individual,  group,  or  organization  who  may  affect,  be  affected  by,  or  perceive  itself  to  be 
affected  by  a decision,  activity,  or  outcome  of  a project. 

Stakeholder  Analysis.  A technique  of  systematically  gathering  and  analyzing  quantitative  and  qualitative 
information  to  determine  whose  interests  should  be  taken  into  account  throughout  the  project. 

Stakeholder  Management  Plan.  The  stakeholder  management  plan  is  a subsidiary  plan  of  the  project  management 
plan  that  defines  the  processes,  procedures,  tools,  and  techniques  to  effectively  engage  stakeholders  in  project 
decisions  and  execution  based  on  the  analysis  of  their  needs,  interests,  and  potential  impact. 

Stakeholder  Register.  A project  document  including  the  identification,  assessment,  and  classification  of  project 
stakeholders. 

Standard.  A document  that  provides,  for  common  and  repeated  use,  rules,  guidelines,  or  characteristics  for 
activities  or  their  results,  aimed  at  the  achievement  of  the  optimum  degree  of  order  in  a given  context. 
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Start  Date.  A point  in  time  associated  with  a schedule  activity’s  start,  usually  qualified  by  one  of  the  following: 
actual,  planned,  estimated,  scheduled,  early,  late,  target,  baseline,  or  current. 

Start-to-Finish  (SF).  A logical  relationship  in  which  a successor  activity  cannot  finish  until  a predecessor  activity 
has  started. 

Start-to-Start  (SS).  A logical  relationship  in  which  a successor  activity  cannot  start  until  a predecessor  activity  has 
started. 

Statement  of  Work  (SOW).  A narrative  description  of  products,  services,  or  results  to  be  delivered  by  the  project. 
Statistical  Sampling.  Choosing  part  of  a population  of  interest  for  inspection. 

Subnetwork.  A subdivision  (fragment)  of  a project  schedule  network  diagram,  usually  representing  a subproject 
or  a work  package.  Often  used  to  illustrate  or  study  some  potential  or  proposed  schedule  condition,  such  as 
changes  in  preferential  schedule  logic  or  project  scope. 

Subproject.  A smaller  portion  of  the  overall  project  created  when  a project  is  subdivided  into  more  manageable 
components  or  pieces. 

Successor  Activity.  A dependent  activity  that  logically  comes  after  another  activity  in  a schedule. 

Summary  Activity.  A group  of  related  schedule  activities  aggregated  and  displayed  as  a single  activity. 

SWOT  Analysis.  Analysis  of  strengths,  weaknesses,  opportunities,  and  threats  of  an  organization,  project, 
or  option. 

Tailor.  The  act  of  carefully  selecting  process  and  related  inputs  and  outputs  contained  within  the  PMBOK ® Guide 
to  determine  a subset  of  specific  processes  that  will  be  included  within  a project’s  overall  management  approach. 

Team  Members.  See  project  team  members. 

Technique.  A defined  systematic  procedure  employed  by  a human  resource  to  perform  an  activity  to  produce  a 
product  or  result  or  deliver  a service,  and  that  may  employ  one  or  more  tools. 

Templates.  A partially  complete  document  in  a predefined  format  that  provides  a defined  structure  for  collecting, 
organizing,  and  presenting  information  and  data. 

Threat.  A risk  that  would  have  a negative  effect  on  one  or  more  project  objectives. 
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Three-Point  Estimate.  A technique  used  to  estimate  cost  or  duration  by  applying  an  average  of  optimistic, 
pessimistic,  and  most  likely  estimates  when  there  is  uncertainty  with  the  individual  activity  estimates. 

Threshold.  A cost,  time,  quality,  technical,  or  resource  value  used  as  a parameter,  and  which  may  be  included  in 
product  specifications.  Crossing  the  threshold  should  trigger  some  action,  such  as  generating  an  exception  report. 

Time  and  Material  Contract  (T&M).  A type  of  contract  that  is  a hybrid  contractual  arrangement  containing  aspects 
of  both  cost-reimbursable  and  fixed-price  contracts.  Time  and  material  contracts  resemble  cost-reimbursable  type 
arrangements  in  that  they  have  no  definitive  end,  because  the  full  value  of  the  arrangement  is  not  defined  at  the 
time  of  the  award.  Thus,  time  and  material  contracts  can  grow  in  contract  value  as  if  they  were  cost-reimbursable- 
type  arrangements.  Conversely,  time  and  material  arrangements  can  also  resemble  fixed-price  arrangements.  For 
example,  the  unit  rates  are  preset  by  the  buyer  and  seller,  when  both  parties  agree  on  the  rates  for  the  category  of 
senior  engineers. 

Time-Scaled  Schedule  Network  Diagram.  Any  project  schedule  network  diagram  drawn  in  such  a way  that  the 
positioning  and  length  of  the  schedule  activity  represents  its  duration.  Essentially,  it  is  a bar  chart  that  includes 
schedule  network  logic. 

To-Complete  Performance  Index  (TCPI).  A measure  of  the  cost  performance  that  is  required  to  be  achieved  with 
the  remaining  resources  in  order  to  meet  a specified  management  goal,  expressed  as  the  ratio  of  the  cost  to  finish 
the  outstanding  work  to  the  remaining  budget. 

Tolerance.  The  quantified  description  of  acceptable  variation  for  a quality  requirement. 

Tornado  Diagram.  A special  type  of  bar  chart  used  in  sensitivity  analysis  for  comparing  the  relative  importance  of 
the  variables. 

Tool.  Something  tangible,  such  as  a template  or  software  program,  used  in  performing  an  activity  to  produce  a 
product  or  result. 

Total  Float.  The  amount  of  time  that  a schedule  activity  can  be  delayed  or  extended  from  its  early  start  date  without 
delaying  the  project  finish  date  or  violating  a schedule  constraint. 

Tree  Diagram.  A systematic  diagram  of  a decomposition  hierarchy  used  to  visualize  as  parent-to-child 
relationships  a systematic  set  of  rules. 
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Trend  Analysis.  An  analytical  technique  that  uses  mathematical  models  to  forecast  future  outcomes  based  on 
historical  results.  It  is  a method  of  determining  the  variance  from  a baseline  of  a budget,  cost,  schedule,  or  scope 
parameter  by  using  prior  progress  reporting  periods’  data  and  projecting  how  much  that  parameter’s  variance  from 
baseline  might  be  at  some  future  point  in  the  project  if  no  changes  are  made  in  executing  the  project. 

Trigger  Condition.  An  event  or  situation  that  indicates  that  a risk  is  about  to  occur. 

Unanimity.  Agreement  by  everyone  in  the  group  on  a single  course  of  action. 

Validate  Scope.  The  process  of  formalizing  acceptance  of  the  completed  project  deliverables. 

Validated  Deliverables.  Deliverables  that  are  result  of  executing  quality  control  process  to  determine  correctness. 

Validation.  The  assurance  that  a product,  service,  or  system  meets  the  needs  of  the  customer  and  other  identified 
stakeholders.  It  often  involves  acceptance  and  suitability  with  external  customers.  Contrast  with  verification. 

Value  Engineering.  An  approach  used  to  optimize  project  life  cycle  costs,  save  time,  increase  profits,  improve 
quality,  expand  market  share,  solve  problems,  and/or  use  resources  more  effectively. 

Variance.  A quantifiable  deviation,  departure,  or  divergence  away  from  a known  baseline  or  expected  value. 

Variance  Analysis.  A technique  for  determining  the  cause  and  degree  of  difference  between  the  baseline  and 
actual  performance. 

Variance  at  Completion  (VAC).  A projection  of  the  amount  of  budget  deficit  or  surplus,  expressed  as  the 
difference  between  the  budget  at  completion  and  the  estimate  at  completion. 

Variation.  An  actual  condition  that  is  different  from  the  expected  condition  that  is  contained  in  the  baseline  plan. 

Velocity.  A measure  of  a team’s  productivity  rate  at  which  the  deliverables  are  produced,  validated,  and 
accepted  within  a predefined  interval.  Velocity  is  a capacity  planning  approach  frequently  used  to  forecast 
future  project  work. 

Verification.  The  evaluation  of  whether  or  not  a product,  service,  or  system  complies  with  a regulation,  requirement, 
specification,  or  imposed  condition.  It  is  often  an  internal  process.  Contrast  with  validation. 

Voice  of  the  Customer.  A planning  technique  used  to  provide  products,  services,  and  results  that  truly  reflect 
customer  requirements  by  translating  those  customer  requirements  into  the  appropriate  technical  requirements  for 
each  phase  of  project  product  development. 
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WBS  Dictionary.  A document  that  provides  detailed  deliverable,  activity,  and  scheduling  information  about  each 
component  in  the  work  breakdown  structure. 

Weighted  Milestone  Method.  An  earned  value  method  that  divides  a work  package  into  measurable  segments, 
each  ending  with  an  observable  milestone,  and  then  assigns  a weighted  value  to  the  achievement  of  each  milestone. 

What- If  Scenario  Analysis.  The  process  of  evaluating  scenarios  in  order  to  predict  their  effect  on  project  objectives. 

Work  Authorization.  A permission  and  direction,  typically  written,  to  begin  work  on  a specific  schedule  activity  or 
work  package  or  control  account.  It  is  a method  for  sanctioning  project  work  to  ensure  that  the  work  is  done  by  the 
identified  organization,  at  the  right  time,  and  in  the  proper  sequence. 

Work  Authorization  System.  A subsystem  of  the  overall  project  management  system.  It  is  a collection  of  formal 
documented  procedures  that  defines  how  project  work  will  be  authorized  (committed)  to  ensure  that  the  work  is 
done  by  the  identified  organization,  at  the  right  time,  and  in  the  proper  sequence.  It  includes  the  steps,  documents, 
tracking  system,  and  defined  approval  levels  needed  to  issue  work  authorizations. 

Work  Breakdown  Structure  (WBS).  A hierarchical  decomposition  of  the  total  scope  of  work  to  be  carried  out  by 
the  project  team  to  accomplish  the  project  objectives  and  create  the  required  deliverables. 

Work  Breakdown  Structure  Component.  An  entry  in  the  work  breakdown  structure  that  can  be  at  any  level. 

Work  Package.  The  work  defined  at  the  lowest  level  of  the  work  breakdown  structure  for  which  cost  and  duration 
can  be  estimated  and  managed. 

Work  Performance  Data.  The  raw  observations  and  measurements  identified  during  activities  being  performed  to 
carry  out  the  project  work. 

Work  Performance  Information.  The  performance  data  collected  from  various  controlling  processes,  analyzed  in 
context  and  integrated  based  on  relationships  across  areas. 

Work  Performance  Reports.  The  physical  or  electronic  representation  of  work  performance  information  compiled 
in  project  documents,  intended  to  generate  decisions,  actions,  or  awareness 

Workaround.  A response  to  a threat  that  has  occurred,  for  which  a prior  response  had  not  been  planned  or  was 
not  effective. 
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A 

AC.  See  Actual  cost 
Acceptance  criteria,  123, 526 
Accepted  deliverables.  See  under  Deliverables 
Accuracy,  228, 526 

level  of,  148, 162, 170, 171,175 
Acquire  Project  Team  process,  255, 447, 526 
inputs,  269 
outputs,  272 
overview,  267-269 
tools  and  techniques,  270-272 
Acquisition,  270, 526 
Acquisition  activities,  265 
Action  item  tracking,  27, 83,  91 
Activity,  526 

Activity  attributes,  185, 526 
as  input,  155, 162, 167, 175 
as  output,  1 53 
Activity  code,  526 
Activity  cost  estimates,  526 
as  input,  163,  210,  322,  361 
as  output,  207 
Activity  duration,  526 
Activity  duration  estimate,  170,  527 

See  also  Estimate  Activity  Durations  process 
as  input,  175,  322 
range  of  possible  results,  172 
Activity  identifier  (ID),  153,  527 
Activity  list,  527 

as  input,  155, 162,167,175 
as  output,  1 52 

Activity  network  diagrams,  246 

See  also  Project  schedule  network  diagram 
Activity  on  Arrow  (AOA),  246 
Activity-on-Node  (AON),  156,  246 


See  also  Precedence  Diagramming  Method 
Activity  resource  requirements,  185,  527 

See  also  Estimate  Activity  Resources  process 
as  input,  167, 175,  259,  361 
as  output,  1 65 

Activity  sequencing.  See  Sequence  Activities  process 

Actual  cost  (AC),  218,  219,  527 

Actual  duration,  527 

Adaptive  life  cycles,  46, 527 

Additional  quality  planning  tools,  240, 527 

Adjusting  leads  and  lags,  527 

ADR.  See  Alternative  dispute  resolution 

Advertising,  376, 527 

AE.  See  Apportioned  effort 

Affinity  diagram,  1 1 5,  245, 528 

Agile  approach,  1, 114, 187 

Agreements,  70, 528 

See  also  Collective  bargaining  agreements;  Service  level 
agreements 
as  input,  211, 382 
as  output,  377-378 
Alternative  analysis,  164, 528 
Alternative  dispute  resolution  (ADR),  378,  384, 388 
Alternatives  generation,  123,  528 
American  National  Standards  Institute  (ANSI),  418 
Analogous  estimating,  169-170, 204-205,  528 
Analytical  techniques,  91-92, 1 03, 1 47-1 48, 1 98, 31 5, 376, 528 
stakeholder  engagement  level,  402-403 
ANSI.  See  American  National  Standards  Institute 
AON.  See  Activity-On-Node 
Application  area,  528 
Applying  leads  and  lags,  528 
Apportioned  effort  (AE),  528 
Approved  change  request,  96,  528 
as  input,  82,  251, 382 
as  output,  99 
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Approved  change  request  review,  252,  528 
Arbitrary  total  float,  1 58 
Arbitration,  388 

Assumption(s),  124, 168,  348,  529 
Assumptions  analysis,  325, 529 
Assumptions  log  updates,  333,  348 
Attribute  sampling,  250, 529 
Audits,  1 35.  See  also  Quality  audits 
configuration  verification  and,  97 
inspections  and,  383 
procurement,  388 
project  success  or  failure,  101 
quality,  247,  556 
risk,  351 , 354,  559 
Authority,  264,  529 

B 

BAC.  See  Budget  at  completion 
Backlog,  529 

Backward  pass,  176, 177, 529 
Balanced  matrix  organization,  23-24 
Bar  chart,  182, 183,529 

Baseline,  76, 88, 1 40, 529.  See  also  Cost  baseline;  Rebaselining; 

Schedule  baseline;  Scope  baseline 
Baseline  schedule,  21 8.  See  also  Schedule  baseline 
Basis  of  estimates,  529 
as  input,  210 
as  output,  208 

Benchmarking,  116,  239, 529 
Best  practices 

benchmarking  and,  116, 239 
discretionary  dependencies  and,  158 
meeting  types  and,  84 
quality  audits  and,  247 
systematic  achievement  of,  7 
Beta  distribution,  171, 206 
Bias,  risk  attitudes  and,  31 1 
Bid(s),  207, 368,  371 . See  also  Proposals 
Bidder.  See  Seller(s) 

Bidder  conferences,  375, 529 
Bottom-up  estimating,  205 
definition,  530 
description  of,  1 64 


Boundaries 
process,  241 
project,  54, 424 

Brainstorming,  115,171, 207,  240 
definition,  530 
meetings  and,  84 
risk  identification  and,  324 
Budget,  365,  530 

Budget  at  completion  (BAC),  89, 21 8, 21 9, 530 

Budgeting,  316 

Budget  reserve  analysis,  21 1 

Buffer(s),  178, 189.  See  also  Reserve 

Buffer  management,  178 

Business  case,  69,  530 

Business  need,  68 

Business  partners,  33, 36 

Business  requirements,  112, 117 

Business  value,  15-16,  530 

Buyer 

definition,  530 
terms  for,  357 

Buyer-seller  relationship,  357 
Buy  versus  lease  decision,  201 

c 

CA.  See  Control  account 

Calendar,  185.  See  also  Project  calendar;  Resource  calendars 

Capability  Maturity  Model  Integrated  (CM Ml®),  229 

Causal  analysis,  91 

Causal  influences,  325-326 

Cause-and-effect  diagram,  236, 325,  530 

CCB.  See  Change  control  board 

Central  tendency,  530 

Certified  Associate  in  Project  Management  (CAPM)®,  1 
Change  control,  530.  See  also  Perform  Integrated  Change 
Control  process 

management  reserves  and,  213 
meetings,  99 
procedures,  27 

Change  control  board  (CCB),  74,  96, 530 
change  management  plan  and,  96 
meetings  and,  99 

Change  control  system,  531 . See  also  Contract  change  control 
system 
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Change  control  tools,  99, 531 
Change  log,  100, 407, 531 
Change  management  plan/system,  138 
Change  request(s). 

See  also  Approved  change  request;  Requested  change 
approved,  528 

approved  change  requests  review,  528 
change  control  board  and,  96 
constructive  change,  384 
corrective  actions  and,  353 
definition,  531 
as  input,  97 

as  output,  85, 136, 140,  225,  247,  253,  284-285,  307-308, 
370,378,  385,408,  413 
preventive  actions  and,  191 , 353 
types  of,  92-93 
updates,  348 

Charter.  See  Project  charter 
Checklist  analysis,  325, 531 
Checklist(s),  254.  See  also  Quality  checklists 
Checksheets,  237,  531 
Claim,  531 

Claims  administration,  384, 531 
Closed  procurements,  389,  531 
Close  Procurements  process,  354, 461 , 531 
inputs,  388 
outputs,  389 
overview,  386-387 
tools  and  techniques,  388-389 
Close  Project  or  Phase  process,  63, 460-461 , 531 
inputs,  102 
outputs,  1 03-1 04 
overview,  100-101 
tools  and  techniques,  102-103 
Closing  Process  Group,  418 
definition,  531 
overview,  57-58,  459-460 
processes  in,  61 

CMMI®.  See  Capability  Maturity  Model  Integrated 

Code  of  accounts,  132,531 

Code  of  Ethics  and  Professional  Conduct , 1 

Collaboration 

project  manager  and,  48, 91 , 1 28,  307 
virtual  collaboration  techniques,  25 


Collective  bargaining  agreements,  203, 268 
Collect  Requirements  process,  105, 430,  531 
inputs,  113 
outputs,  117-119 
overview,  110-112 
tools  and  techniques,  114-117 
Colocated  teams,  25, 277,  532 
See  also  Project  team(s);  Team 
Commercial  information,  published,  204 
Communication 

See  also  Control  Communications  process 
activity,  dimensions  of,  287 
channels,  81,176,  292,293,  294 
constraints,  532 
correspondence,  386 
diverse  stakeholders  and,  287 
informal,  274,  282 
methods,  294-295,  407,  532 
models,  293-294,  298,  300,  532 
organizational,  20 
project,  301 , 305 
skills,  288 
styles,  21 

technology,  38,  292-293,  300 
Communication  planning 

See  also  Plan  Communications  process;  Project 
Communications  Management 
Communication  requirements  analysis,  291-292,  532 
Communications  management  plan,  296-297,  532 
as  input,  299, 406 

Communication  technologies,  38,  292-293,  300, 532 
See  also  E-mail;  Web  conferencing 
Competency,  264 
Compliance,  267,  532 
Composite  organization,  25, 26 
Concurrent  project  phases,  42 
Conduct  Procurements  process,  354, 449,  532 
inputs,  373-375 
outputs,  377-379 
overview,  371-373 
tools  and  techniques,  375-377 
Confidentiality,  293 
Configuration  control,  96 
Configuration  identification,  96 
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Configuration  management  plan,  138 
Configuration  management  system 
change  requests  and,  96 
definition,  532 

Configuration  status  accounting,  97 
Configuration  verification  and  audit,  97 
Conflict  management,  282-283,  532 
Conformance,  235, 532 
Conformance  work,  533 
Constraints,  5, 124, 168, 365,  533 
Context  diagrams,  1 1 7, 533 
Contingency,  533 

Contingency  allowance.  See  Reserve 
Contingency  plan,  348 

Contingency  reserve,  171, 206, 213, 348, 533 
See  also  Reserve  analysis 
Contingent  response  strategies,  346,  533 
Continuous  distributions,  337 
Continuous  improvement,  229 
Contract(s),  533 

See  also  Time  and  Material  Contract  (T&M); 

Union  labor/contracts 
amendments  to,  381 
closure  of,  366,  373,  381 
communications  and,  386 
cost-reimbursable,  363-364,  535 
documentation,  389 
early  termination  of,  387 
legal  implications  of,  203, 357,  380, 387 
procurement  contract,  357 
procurement  negotiations  and,  375 
requirements  of,  96,  282, 384 
termination  clause,  378, 380 
terms  and  conditions,  387 
types  of,  362-363 

Contract  change  control  system,  383, 533 
Contract  management,  355 
Contractor.  See  Seller(s) 

Contractor  conferences.  See  Bidder  conferences 
Control,  88,  533 
Control  account  (CA),  132,  533 
Control  chart,  238, 533 

Control  Communications  process,  287, 456-457, 533 
inputs,  304-306 


outputs,  307-308 
overview,  303-304 
tools  and  techniques,  306-307 
Control  Costs  process,  193, 455, 534 
inputs,  216-217 
outputs,  225-226 
overview,  215-216 
tools  and  techniques,  217-225 
Control  limits,  534.  See  also  Specification  limits 
Control  Procurements  process,  354, 458,  534 
inputs,  381-382 
outputs,  384-386 
overview,  379-381 
tools  and  techniques,  383-384 
Control  Quality  process,  227, 456, 534 
inputs,  250-251 
outputs,  252-254 
overview,  248-250 
tools  and  techniques,  252 
Control  Risks  process,  309, 457, 534 
inputs,  350-351 
outputs,  353-354 
overview,  349-350 
tools  and  techniques,  351-352 
Control  Schedule  process,  141 , 454-455, 534 
inputs,  187-188 
outputs,  1 90-1 92 
overview,  1 84-1 87 
tools  and  techniques,  188-190 
Control  Scope  process,  105, 454, 534 
inputs,  137-138 
outputs,  1 39-1 40 
overview,  1 36-1 37 
tools  and  techniques,  139 

Control  Stakeholder  Engagement  process,  391 , 458-459, 534 
inputs,  411-412 
outputs,  41 3-41 5 
overview,  409-41 0 
tools  and  techniques,  41 2-41 3 
Control  thresholds,  148, 199 
COQ.  See  Cost  of  quality 
Corrective  action,  81 

change  request  for,  85, 93, 353 
definition,  534 


572  ©201 3 Project  Management  Institute.  A Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKB  Guide)  - Fifth  Edition 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


INDEX 


Correspondence,  386 
Cost(s).  See  also  Actual  cost 
aggregation  of,  21 1 , 534 
indirect,  202,  207,218,365 
and  time  objectives,  341 
Cost  aggregation,  21 1 , 534 
Cost  baseline,  1 91 , 21 6,  226,  233,  534 
as  output,  21 2-21 4,  385 
updates,  347 

Cost-benefit  analysis,  235, 535 
Cost  contingency  reserve,  207, 349 
Cost  control.  See  Control  Costs  process 
Cost  estimating.  See  Estimate  Costs  process 
Cost  forecasts,  89,  225 

Cost  management.  See  Project  Cost  Management 
Cost  management  plan,  216, 226,  534 
as  input,  202,209,321,335 
updates,  347 

Cost  of  quality  (COQ),  206,  229,  231 , 235,  535 
Cost  performance  index  (CPI),  89, 219,  535 
Cost  performance  measurements,  222 
Cost  Plus  Award  Fee  contract  (CPAF),  364,  535 
Cost-plus  contract,  344 
Cost  Plus  Fixed  Fee  (CPFF)  contract,  364, 535 
Cost  Plus  Incentive  Fee  (CPIF)  contract,  364, 535 
Cost-reimbursable  contracts,  363-364,  535 
Cost  risk  simulation,  340 
Cost  variance  (CV),  89,  218-219, 535 
CPAF.  See  Cost  Plus  Award  Fee  contract 
CPFF.  See  Cost  Plus  Fixed  Fee 
CPI.  See  Cost  performance  index 
CPIF.  See  Cost  Plus  Incentive  Fee  (CPIF)  contract 
CPM.  See  Critical  path  method 
Crashing,  181, 190, 535 
Create  WBS  process,  1 05, 431 , 535 
inputs,  127 
outputs,  131-132 
overview,  1 25-1 26 
tools  and  techniques,  128-131 
Criteria,  536 
Critical  chain,  178 

Critical  chain  method  (CCM),  142, 178, 188,  536 
Critical  path,  176,  536 
Critical  path  activity,  177,  536 


Critical  path  method  (CPM),  142, 176-177, 188,  246,  536 
Cultural  diversity 

cross-cultural  considerations,  290 
multinational  team,  294 
projects  characterized  by,  274 
recognition  and  rewards,  277 
Culture.  See  Organizational  culture 
Customer(s) 
definition,  536 
external,  70, 380 
in  project  team,  36 
request,  9 
requirements,  228 
users  and,  32 

Customer  satisfaction,  229, 536 
CV.  See  Cost  variance 

D 

Data  date,  536 

Data  gathering  and  representation  techniques,  536 
interviewing,  336 
probability  distributions,  337 
Decision  making 

business  case  and,  69 
effective,  284 

quantitative  risk  information  and,  333, 441 
Decision-making  skills,  284 
Decision  tree  analysis,  339, 536 
Decoding/encoding  of  messages,  293-294 
Decomposition,  112, 536 
excessive,  131 

into  work  packages,  1 20-1 31 , 1 28 
Dedicated  project  team,  37 
Defect(s),  3 
definition,  536 
identification  of,  237 
number  of,  59, 85, 228 
prevention  of,  229, 243 
Defect  repair,  81 

change  request  for,  82,  85, 93, 97, 140 
definition,  536 
quality  audits  and,  247 
Define  Activities  process,  141, 432,  536 
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inputs,  150-151 
outputs,  1 52-1 53 
overview,  149-150 
tools  and  techniques,  151-152 
Define  Scope  process,  105, 430, 537 
inputs,  121-122 
outputs,  1 23-1 24 
overview,  120-121 
tools  and  techniques,  122-123 
Deliverable(s).  See  also  Result;  Verified  deliverables 
accepted,  102, 135,  389, 526 
definition,  84, 123, 537 
as  input,  251 
as  output,  84 
validated,  566 
verified,  134, 135 

Delphi  technique,  171, 207,  324, 537 
Dependency.  See  Logical  relationship 
Dependency  determination,  537 
discretionary  dependencies,  158 
external  dependencies,  158 
internal  dependencies,  158 
mandatory  dependencies,  157, 545 
Design  of  experiments  (DOE),  239-240, 537 
Determine  Budget  process,  193, 437, 537 
inputs,  209-211 
outputs,  212-214 
overview,  208-209 
tools  and  techniques,  211-212 
Develop  Project  Charter  process,  63, 426,  537 
inputs,  68-70 
outputs,  71-72 
overview,  66-68 
tools  and  techniques,  71 

Develop  Project  Management  Plan  process,  63,  429,  537 
inputs,  74-75 
outputs,  76-78 
overview,  72-74 
tools  and  techniques,  76 
Develop  Project  Team  process,  255,  447,  537 
inputs,  274-275 
outputs,  278-279 
overview,  273-274 
tools  and  techniques,  274-278 


Develop  Schedule  process,  141 , 434-435, 537 
inputs,  175-176 
outputs,  181-184 
overview,  1 72-1 74 
tools  and  techniques,  176-180 
Diagramming  techniques,  325-326, 537 
Dictatorship,  115,  537 

Direct  and  Manage  Project  Work  process,  63, 445-446, 538 
inputs,  82-83 
outputs,  84-86 
overview,  79-81 
tools  and  techniques,  83-84 
Discounted  cash  flow,  195, 198 
Discrete  effort,  538 
Discretionary  dependencies,  158,  538 
Diversity.  See  Cultural  diversity 
Document(s).  See  also  Project  documents 
analysis  of,  117,  538 
archival  of,  460 
management,  hard-copy,  300 
phase  closure,  104 

Documentation.  See  also  Requirements  documentation 
lessons  learned,  254,  303, 389, 409, 415 
reviews,  324,  538 
seller  performance  evaluation,  382 
technical,  348 
written,  386 

DOE.  See  Design  of  experiments 
DU  or  DUR.  See  Duration 

Duration  (DU  or  DUR),  538.  See  also  Most  likely  duration; 

Optimistic  duration;  Pessimistic  duration 
Duration  estimates.  See  Activity  duration  estimates; 
Estimate  Activity  Durations  process 

E 

EAC.  See  Estimate  at  completion 
EAC  forecasts,  220-221 
Early  Finish  date  (EF),  538 
Early  Start  date  (ES),  538 
Earned  value  (EV),  132,  218, 219,  538 
analysis,  224, 351 

Earned  value  management  (EVM),  92, 149, 189 
cost  management  plan  and,  199 
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definition,  538 
reports,  96 

work  packages,  control  accounts  and,  217-219 
Earned  value  performance,  223 
EF.  See  Early  Finish  date 
Effort,  538 

Emotional  intelligence,  538 

Employees.  See  also  Human  resource  management  plan; 
Staffing  management  plan 
morale  of,  266,  274 
motivation  of,  273, 447 
virtual  teams  and,  271 

EMV.  See  Expected  Monetary  Value  (EMV)  analysis 
Encoding/decoding  of  messages,  293-294 
Enterprise  environmental  factors,  29, 127,  539 

examples  of,  1 46, 1 51 , 1 55, 1 69, 1 97,  203-204,  234 
as  input,  70,  74-75,  82,  90,  98, 108, 163, 176,  259,  269, 
291 , 299,  324,  330,  335,  362,  395,  401 
updates,  279, 285 
Environmental  consideration,  9 
ES.  See  Early  Start  date 
Escalation  procedures,  259 

Estimate,  376,  539.  See  also  Analogous  estimating;  Basis  of 
estimates;  Independent  estimates;  Parametric  estimating; 
Three-point  estimate 

Estimate  Activity  Durations  process,  141, 433-434,  539 
inputs,  167-169 
outputs,  1 72 
overview,  1 65-1 67 
tools  and  techniques,  169-171 
Estimate  Activity  Resources  process,  141 , 433, 539 
inputs,  162-163 
outputs,  1 65 
overview,  160-162 
tools  and  techniques,  164 

Estimate  at  completion  (EAC),  89, 1 99, 220-221 , 539 
Estimate  Costs  process,  193, 436, 539 
inputs,  202-204 
outputs,  207-208 
overview,  200-202 
tools  and  techniques,  204-207 
Estimate  to  complete  (ETC),  89,  219-220,  539 
ETC.  See  Estimate  to  complete 
EV.  See  Earned  value 


EVM.  See  Earned  value  management 
Execute,  539 

Executing  Process  Group,  418,  444-445 
definition,  539 
overview,  56 
processes  in,  61 

Expected  Monetary  Value  (EMV)  analysis,  339,  539 
Expert  judgment,  76,  91 , 98-99, 1 09, 1 22, 1 28, 1 47, 1 52, 
164, 169, 198,  204,  211, 263,  306-307,  315,  327,  333, 
341 , 346,  365,  376,  397-398,  401-402,  41 2,  539 
External  dependencies,  158,  540 

F 

Facilitated  workshops,  114, 123,  540 
Facilitation  techniques,  71 , 76 
Failure  costs,  235 

Failure  mode  and  effect  analysis  (FMEA),  92, 540 

Fallback  plan,  343,  348, 540 

Fast  tracking  techniques,  43, 1 47, 1 58, 1 81 , 1 90, 540 

Fault  tree  analysis  (FTA),  92 

Fee,  540 

Feeding  buffers,  178 

FF.  See  Finish-to-finish 

FFP.  See  Firm-fixed-price  contract 

Final  product,  service,  or  result  transition,  103 

Finish  date,  540 

Finish-to-finish  (FF),  154, 156,  540 
Finish-to-start  (FS),  154, 156, 540 
Firm  Fixed  Price  contract  (FFP),  363,  540 
Fishbone  diagram,  236, 325.  See  also  Cause-and-effect 
diagram 

Fixed  formula  method,  540 
Fixed-price  contracts,  362-363,  540 
Fixed  Price  Incentive  Fee  contract  (FPIF),  363, 541 
Fixed  Price  with  Economic  Price  Adjustment  contracts  (FP-EPA), 
363,  541 

Float.  See  Free  float;  Total  float 
Flowcharts,  236,  541 

FMEA.  See  Failure  mode  and  effect  analysis 
Focus  groups,  1 1 4,  278,  402,  41 2,  541 
Force  field  analysis,  240 
Forecast(s) 
cost,  89, 225 
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definition,  541 
schedule,  89, 561 
Forecasting  methods,  92, 220-221 
Forming,  storming,  norming,  performing,  adjourning,  276 
FP-EPA 

See  Fixed  Price  with  Economic  Price  Adjustment  contract 
FPIF.  See  Fixed  Price  Incentive  Fee  contract 
FPP  See  Firm  Fixed  Price  contracts 
Fragment  network.  See  Subnetwork 
Framework  for  standard,  41 8-41 9 
Free  float,  177, 541 
FS.  See  Finish-to-start 
FTA.  See  Fault  tree  analysis 
Fully  plan-driven  life  cycles.  See  Predictive  life  cycle 
Functional  manager,  33,  541 
Functional  organization,  22, 541 
Function  points,  250 
Funding  limit  reconciliation,  212, 542 
Funding  requirements,  214 

G 

Gantt  chart,  182, 542 
Globalization/global  environment 
cultural  diversity  and,  274 
cultural  influences  and,  21 
international  factors,  272 
Governance.  See  also  Project  governance 
organizational,  13 
project,  34-35, 553 

Government  jurisdictions,  376.  See  also  Regulatory  bodies 

Government  regulations,  68, 267 

Grade  of  products/services,  228, 542 

Graphical  analysis  techniques,  223 

Ground  rules,  project  team,  277,  542 

Group  creativity  techniques,  1 1 5,  542 

Group  decision-making  techniques,  115-116,1 35, 1 71 , 207, 542 

Grouping  methods,  91 

Guideline,  542 

H 

Flammock  activity,  1 82.  See  also  Summary  activity 
Hard  logic,  157.  See  also  Mandatory  dependency 


Hierarchical-type  organization  charts,  261 
High-level  plan,  45, 316 

High-level  project/product  description,  72, 108, 121, 314 
High-level  requirements,  55, 71 , 1 1 7, 31 4, 425 
High-level  vision,  45, 121 
High-performance  teams,  278 
Histograms,  238,  265-266,  340,  542 
Historical  information,  104, 542 
Historical  relationships,  21 2 
Human  resource  management  plan,  264-267, 542 
as  input,  202,269,274,  281,322 
roles  and  responsibilities,  264 
updates,  347 

Human  resource  requirements 
See  Staffing  management  plan 

I 

ID.  See  Activity  identifier 
Idea/mind  mapping,  115, 542 
Identified  risks,  list  of,  327 
Identify  Risks  process,  309, 440, 542 
inputs,  320-324 
outputs,  327 
overview,  319-321 
tools  and  techniques,  324-327 
Identify  Stakeholders  process,  391 , 426,  543 
inputs,  394-395 
outputs,  398 
overview,  394-395 
tools  and  techniques,  395-398 
IFB.  See  Invitation  for  bid 
Imposed  date,  543 
Incentive  fee,  543 
Incremental  life  cycle,  543 
Independent  estimates,  376,  543 
Indirect  costs,  202,207, 218,365 
Inflation  allowance,  202,  207 
Influence  diagram,  325-326, 543 
Influence/impact  grid,  stakeholder  analysis,  396 
Influencing  skills,  284 

Information.  See  also  Documentation;  Project  information 
confidentiality/sensitivity  of,  293 
and  report  flow,  59 
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urgency  of  need  for,  292 

Information  gathering  techniques,  324-325, 543 
Information  management  systems,  300,  306, 412,  543 
See  also  Project  management  information  system 
Information  storage  and  retrieval 
See  Corporate  knowledge  base 
Initiating  Process  Group,  418,  543 
overview,  54-55, 424-425 
processes  in,  61 
project  boundaries  and,  54 
Input,  543.  See  also  specific  process 
Inspection(s),  135 
audits  and,  383, 543 
description  of,  252 
Integrated  change  control 

See  Perform  Integrated  Change  Control  process 
Interactive  communication,  295 
Internal  dependencies,  158 
International  Organization  for  Standardization 
(ISO),  228,418 

Interpersonal  skills,  17-18,  283-284, 407 
communication  skills,  288 
decision  making,  284 
definition,  544 
influencing,  284 
leadership,  284 
as  “soft  skills,”  275 
Interrelationship  diagraphs,  245, 544 
Interviews,  114,  325, 336,  544 
Invitation  for  bid  (IFB),  368, 544 
IPECC,  231 

Ishikawa  diagrams,  236,  325 

ISO.  See  International  Organization  for  Standardization 

Issue,  310,  544 

Issue  log,  544 

as  input,  281, 305,  411 
as  output,  408,414 

Iterative  and  incremental  life  cycles,  45-46 
Iterative  life  cycle,  121, 544 

J 

JAD 

See  Joint  Application  Development  (or  Design)  (JAD)sessions 


Joint  Application  Development  (or  Design)  (JAD)  sessions,  114 
Joint  venture,  19, 37,  347 
Judgment.  See  Expert  judgment 

K 

Key  performance  indicators  (KPIs),  84 
Knowledge  Areas 

mapping  of,  422-423 
Process  Groups  and,  61 

Project  Communications  Management,  289-290,  553 

Project  Cost  Management,  192-195,  553 

Project  Human  Resource  Management,  255-257,  554 

Project  Integration  Management,  63-65, 554 

Project  Procurement  Management,  355-358, 555 

Project  Quality  Management,  227,  555 

Project  Risk  Management,  309-312, 555 

Project  Scope  Management,  105,  555 

Project  Time  Management,  142,  556 

role  of,  60 

Knowledge  base,  lessons  learned,  151, 544 
KPIs.  See  Key  performance  indicators 

L 

Lag(s),  180 

adjusting,  190, 527 
applying,  528 
definition,  159,  544 
example  of,  158 
Late  finish  date  (LF),  544 
Late  start  date  (LS),  544 
Leadership  skills,  284 
Lead(s),  180 

adjusting,  190, 527 
applying,  528 
definition,  544 
example  of,  158 
Lean  Six  Sigma,  229 
Legal  requirements,  9, 31 

contractual  obligations,  203, 361, 380,  387 
Lessons  learned,  259 
definition,  544 

documentation,  254, 303,  389, 409, 415 
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knowledge  base,  151, 544 
Leveling.  See  Resource  leveling 
Level  of  accuracy,  148, 199 
Level  of  effort  (LOE),  153,  545 
Level  of  precision,  199 
LF.  See  Late  finish  date 

Life  cycle.  See  Incremental  life  cycle;  Iterative  life  cycle; 

Predictive  life  cycle;  Product  life  cycle;  Project  life  cycle 
LOE.  See  Level  of  effort 
Log,  545.  See  also  Issue  log 
Logical  relationship,  154, 159, 545 
See  also  Precedence  relationship 
LS.  See  Late  start  date 

M 

Majority,  115, 545 

Make-or-buy  analysis,  360, 365,  545 
Make-or-buy  decisions,  370, 545 
as  input,  374 

Manage  Communications  process,  287,  448,  545 
inputs,  299-300 
outputs,  300-303 
overview,  297-299 
tools  and  techniques,  300-301 
Management.  See  also  Portfolio  management;  Program 
management;  Project  management;  Project  Quality 
Management 
responsibility,  229 
skills,  408,  545 

Management  reserve,  1 71 , 206,  21 3, 545 
See  also  Reserve 

Manage  Project  Team  process,  255, 448,  545 
inputs,  280-281 
outputs,  284-285 
overview,  279-280 
tools  and  techniques,  282-284 
Manager(s).  See  also  Project  manager 
functional,  33, 541 
program,  14 

Manage  Stakeholder  Engagement  process,  391 , 449-450, 545 
inputs,  406-407 
outputs,  408-409 
overview,  404-406 


tools  and  techniques,  407-408 
Mandatory  dependency,  157, 545 
Market  research,  365, 546 
Master  schedule,  546.  See  also  Schedule 
Material,  546 

Matrix-based  responsibility  charts,  262 
Matrix  diagrams,  246,  546 
Matrix  organization(s),  21 , 22-24,  546 
Meetings,  307,  352,  398,  402 
change  control  board  and,  99 
participants  in,  109, 148, 198, 241 
potential  bidders  and,  366 
project-related,  295 
risk  management  and,  31 6 
status  review,  297, 352, 413 
types  of,  84,92,103 
“war  room”  for,  277 
Methodology,  546 
Metrics.  See  Quality  metrics 
Milestone.  See  also  Weighted  milestone  method 
closure  of  phase,  41 
definition,  546 
zero  duration  of,  153 
Milestone  charts,  182, 183 
Milestone  list,  546 
as  input,  155 
as  output,  1 53 

Milestone  schedule,  546.  See  also  Master  schedule 
Mind  mapping,  115, 542 
Mitigation.  See  Risk  mitigation 
Modeling 

simulation  and,  340 
techniques,  180, 189 
Monitor,  546 

Monitor  and  Control  Project  Work  process,  63, 452, 546 
inputs,  88-91 
outputs,  92-94 
overview,  86-88 
tools  and  techniques,  91-92 
Monitoring  and  Controlling  Process  Group,  418,  546 
as  “background”  process,  50 
overview,  57, 450-451 
processes  in,  61 
project  or  phase  closure,  57 
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Monte  Carlo  simulation,  171, 340,  547 
Most  likely  duration,  547.  See  also  Duration 
Multi-criteria  decision  analysis,  115,  271-272,  547 
Multiphase  projects,  51, 57, 69, 387, 419, 451 

N 

Near-critical  activity,  547 
Negative  risks,  203,  31 0, 31 1 , 344-345 
Negotiated  settlements,  547 
Negotiation,  547 
invitation  for,  368 
procurement,  377 
staff  assignments  and,  270 
Network.  See  Project  schedule  network  diagram 
Network  analysis.  See  Schedule  network  analysis 
Networking,  263,  547 
Network  logic,  547 
Network  path,  547 

Network  schedule  analysis  activity,  176 
Node,  547 

Nominal  group  technique,  1 1 5, 1 71 , 207, 240,  547 
Nonconformance,  229 
cost  of,  235 
work,  548 

0 

Objective,  548 

OBS.  See  Organizational  breakdown  structure 

Observations,  116,  282, 548 

Operational  stakeholders,  13-14 

Operations  management,  12 

OPM.  See  Organizational  Project  Management 

0PM3®.  See  Organizational  Project  Management  Maturity  Model 

Opportunities,  345-346,  548 

Optimistic  duration,  548.  See  also  Duration 

Organization(s) 

project  management  and,  1 4-1 5 
Organizational  breakdown  structure  (OBS),  245,  261 , 548 
Organizational  characteristics,  21-26 
Organizational  charts,  131 , 258, 292 
Organizational  culture.  See  also  Cultural  diversity 
project  team  composition  and,  37 


styles  and,  20-21 
Organizational  groups,  33 

Organizational  knowledge  base.  See  Corporate  knowledge  base 
Organizational  procedures  links,  148, 199 
Organizational  process  assets,  23-24 
corporate  knowledge  base,  28 
definition,  548 

examples  of,  1 47, 1 51 , 1 56, 1 63, 1 69,  21 7,  234,  251 
as  input,  70,  75,  83,  91 , 98, 1 02, 1 09, 1 22, 1 27, 1 39, 1 88, 

1 97,  204,  21 1 , 259,  281 , 291 , 299-300,  306,  324,  330, 
336,362,375,395,  401,407 
processes  and  procedures,  27-28 
updates,  103, 140, 192,  226,  248,  254,  285,  302-303,  308, 
354,  389,  409,415 

Organizational  project  management  (OPM),  7 
Organizational  project  management  maturity,  548 
Organizational  strategy 

project  management,  operations  management  and,  11 
project  management  and,  1 5 
Organizational  structures,  21-26 
composite  organization,  26 
functional  organization,  22 
interactions  and,  26 
matrix  organizations,  22-24 
overlapping  project  phases,  43-44 
projectized  organization,  25 
project-related  characteristics,  21 
reporting  relationships  and,  17 
Organizational  theory,  263 

Organization  charts  and  position  descriptions,  261-262 
hierarchical-type  charts  and,  261 
matrix-based  charts,  262 
text-oriented  formats,  262 
Output(s),  548 

Overlapping  project  phases,  43 

P 

Parametric  estimating,  170, 205,  548 

Pareto  diagram,  237,  548 

Path  convergence,  548 

Path  divergence,  548 

Payment  systems,  383,  548 

PBOs.  See  Project-based  organizations  (PBOs) 
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PDCA.  See  Plan-do-check-act  (PDCA)  cycle 
PDM.  See  Precedence  Diagramming  Method 
PDPC.  See  Process  Decision  Program  Charts  (PDPC) 

Percent  complete,  549 
Performance  appraisals,  282 
Performance  measurement  baseline  (PMB),  302,  549 
Performance  reporting,  300, 383. 

See  also  Work  performance  reports 
Performance  reviews,  188-189, 222-223,  549 
procurement,  383,  552 

Performing  organization,  549.  See  also  Seller(s) 

Perform  Integrated  Change  Control  process,  63, 452-453,  549 
inputs,  97-98 
outputs,  99-1 00 
overview,  94-97 
tools  and  techniques,  98-99 

Perform  Qualitative  Risk  Analysis  process,  309, 440-441 , 549 
inputs,  329-330 
outputs,  333 
overview,  328-329 
tools  and  techniques,  330-333 
Perform  Quality  Assurance  process,  227, 446, 549 
inputs,  244-245 
outputs,  247-248 
overview,  242-244 
tools  and  techniques,  245-247 
Perform  Quantitative  Risk  Analysis  process,  309, 441, 549 
inputs,  335-336 
outputs,  341 
overview,  333-335 
tools  and  techniques,  336-341 
Personnel  assessment  tools,  278 
PERT.  See  Program  Evaluation  and  Review  Technique 
Pessimistic  duration,  549.  See  also  Duration 
Phase.  See  Project  phase(s) 

Phase  closure,  104.  See  also  Close  Project  or  Phase  process 
Phase  gate,  41 , 549 
Phase-to-phase  relationships,  42-44 
overlapping  relationship,  43 
sequential  relationship,  42 

Plan  Communications  Management  process,  287, 439,  549 
inputs,  290-291 
outputs,  296-297 
overview,  289-290 


tools  and  techniques,  291-295 
Plan  Cost  Management  process,  193, 435-436, 550 
inputs,  196-197 
outputs,  1 98-200 
overview,  1 95-1 96 
tools  and  techniques,  198 
Plan-do-check-act  (PDCA)  cycle,  229 
Plan  Human  Resource  Management  process,  255, 438,  550 
inputs,  259-260 
overview,  258-259 
tools  and  techniques,  261-264 
Planned  risk  responses,  104, 347-348 
Planned  value  (PV),  218,  219,550 
Planning  package,  132,  550.  See  also  Control  account 
Planning  Process  Group,  418,  550 
overview,  55-56,  427-428 
processes  in,  61 

Plan  Procurement  Management  process,  354, 442-443,  550 
inputs,  360-364 
outputs,  366-370 
overview,  358-360 
tools  and  techniques,  355-356 
Plan  Quality  Management  process,  227, 437-438, 550 
inputs,  233-234 
outputs,  241-242 
overview,  230-233 
tools  and  techniques,  235-241 
Plan  Risk  Management  process,  309, 430, 550 
inputs,  314-315 
outputs,  316-318 
overview,  313-314 
tools  and  techniques,  315-316 
Plan  Risk  Responses  process,  309, 442, 550 
inputs,  343 
outputs,  346-347 
overview,  342-343 
tools  and  techniques,  343-346 
Plan  Schedule  Management  process,  1 41 , 431 , 550 
inputs,  146-147 
outputs,  1 48-1 49 
overview,  145-146 
tools  and  techniques,  147-148 
Plan  Scope  Management  process,  105, 429,  550 
inputs,  108-109 
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outputs,  1 09-1 1 0 
overview,  107-108 
tools  and  techniques,  109 

Plan  Stakeholder  Management  process,  391 , 443, 550 
inputs,  400-401 
outputs,  403-404 
overview,  399-400 
tools  and  techniques,  401-403 
Plurality,  115,550 
PM.  See  Project  manager 

PMB.  See  Performance  measurement  baseline;  PV  baseline 
PMIS.  See  Project  Management  Information  System 
PMO.  See  Project  management  office 
Policy,  550 
Portfolio,  551 

Portfolio  management,  551 
Positive  risks,  31 1 , 345-346 
Power/influence  grid,  stakeholder  analysis,  396 
Power/interest  grid,  stakeholder  analysis,  396 
Pre-assignment  of  team  members,  270 
Pre-bid  conferences.  See  Bidder  conferences 
Precedence  Diagramming  Method  (PDM),  156-157,  246, 551 
Precedence  relationship,  156-157,  551. 

See  also  Logical  relationship 
Precision,  228, 551 

Predecessor  activity,  156, 158-159, 180,  551 

Predictive  life  cycle,  44-45,  551 

Preferential  logic,  1 58.  See  also  Discretionary  dependencies 

Presentations,  302, 409, 415 

Prevention,  229,  250 

Preventive  action,  81 , 551 

change  request  for,  93, 1 91 , 353 
characteristics  of,  85 
Prioritization  matrices,  246, 551 
Probabilistic  analysis  of  project,  341 
Probability  and  impact  matrix,  318,  331-332,  551 
Probability  distributions,  337 
Procedure,  551 
Process  analysis,  247, 552 
Process  assets.  See  Organizational  process  assets 
Process  closure.  See  Closing  Process  Group 
Process  Decision  Program  Charts  (PDPC),  245,  552 
Process(es) 
definition,  551 


descriptions  of,  50, 149,  200 
Processes  and  procedures,  27-28 

See  also  specific  process  or  procedure 
Process  flow  charts,  325 
Process  flow  diagram,  419-420 
Process  Groups 

categories  of,  48-49 
Closing  Process  Group,  57-58 
Executing  Process  Group,  56 
Initiating  Process  Group,  54-55 
interactions  of,  51 , 420-421 
Knowledge  Areas  mapping  and,  61 
Monitoring  and  Controlling  Process  Group,  57 
as  overlapping  activities,  51 
overview,  5,  52-53 
Planning  Process  Group,  55-56 
Process  improvement  models,  229 
Process  improvement  plan,  552 
as  input,  244 
as  output,  241 
Process  interactions. 

See  Project  management  process  interactions 
Procurement  audits,  388, 552 
Procurement  documents,  552 
as  input,  323,  373,  382,  388,  394 
as  output,  368 

procurement  contract,  357,  380 
Procurement  file,  389 
Procurement  management  plan,  552 
as  input,  373 
as  output,  366-367,  385 
updates,  347 

Procurement  negotiations,  377, 388 
Procurement  performance  reviews,  383, 552 
Procurement  statement  of  work,  552 
as  input,  374 
as  output,  367 
Product,  552 

Product  analysis,  122,552 

Product  life  cycle,  552 

Product-oriented  processes,  47-48 

Product  quality  improvement,  229 

Product  requirements,  64, 1 06, 1 1 4, 1 1 5, 1 1 8, 227 

Product  scope,  105, 552 
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Product  scope  description,  68, 1 23, 552 
Program(s),  553 

Program  Evaluation  and  Review  Technique  (PERT),  170, 

246,  553 

Program  management 
definition,  553 
description  of,  9 
OPM  and,  6 

portfolio  management  and,  6-7 
project  management  and,  6-7 
Program  manager,  14 
Progressive  elaboration,  5 
definition,  553 

project  management  plan  and,  55 
prototypes  and,  116 
rolling  wave  planning  as,  151 
Project(s) 

boundaries,  54, 424 
definition,  3-4, 417, 553 
portfolios,  programs  and,  4-5 
temporary  nature  of,  35 
Project-based  organizations  (PBOs),  14, 553 
Project  boundaries,  54, 424 
Project  calendar,  553 
as  input,  188 
as  output,  1 84 

Project  charter,  553.  See  also  Develop  Project  Charter  process 
authorization  and,  54, 424 
description  of,  67 

as  input,  74, 1 08, 1 1 3, 1 21 , 1 46, 1 97,  394 
as  output,  71-72 
project  scope  statement  and,  124 
Project  closure 

documents,  104, 354 
guidelines,  75 

Project  communication  requirements. 

See  Communication  requirements  analysis 
Project  communications,  301 , 305 
Project  Communications  Management,  287-308 
definition,  553 
overview,  287-288 

Project  Cost  Management,  193-226, 553 
Project  documents.  See  also  Documents 
as  input,  245,  251 , 323,  374, 411-41 2 


project  management  plan  and,  78 
updates,  86,  94, 100, 125, 132, 136, 140, 160, 165, 172, 
185, 191, 208,  214,  226,  242,  248,  285,  297,  302,  308, 
333,  341 , 354,  370,  379,  385,  404,  409 
Project  execution.  See  Executing  Process  Group 
Project  files,  104 

Project  funding  requirements,  553 
as  input,  217 
as  output,  214 

Project  governance,  34-35, 553.  See  also  Governance 
Project  Human  Resource  Management,  255-285,  554 
Project  initiation,  554 
Project  Integration  Management,  63-104 
definition,  554 
overview,  63-65 
Projectized  organization,  25,  556 
Project  life  cycle 

adaptive  life  cycles,  46 
characteristics  of,  38-40 
cost,  staffing  levels  and,  39-40 
definition,  38, 554 

iterative  and  incremental  life  cycles,  45-46 
overview,  38 

predictive  life  cycles,  44-45 
project  time  and,  39 
Project  management 
business  value  and,  16 
definition,  417, 554 
description  of,  5-6 
iterative  nature  of,  422 
operational  stakeholders  in,  13-14 
operations  management  and,  12 
organizational  governance  and,  13 
organizational  influences  on,  19 
organizational  strategy  and,  11,15 
organizations  and,  14-15 
Process  Groups  in,  5 

process  interactions,  50-51 , 53, 422-423 
Project  management  body  of  knowledge,  554 
Project  management  information  system  (PMIS),  57, 58, 92, 
151,155,460,  554 

Project  Management  Knowledge  Areas,  554 
Project  management  office  (PMO),  99, 554 
Project  management  plan,  554. 
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See  also  Develop  Project  Management  Plan  process 

components  and  project  documents,  78 

cost  control  and,  216 

cost  management  plan  and,  196 

elements  of,  146 

as  input,  82,  88-89,  97, 102, 108, 134, 187,  233,  250,  259, 
290,  304-305,  31 4,  350,  360,  381 , 388,  400,  41 1 
as  output,  76-77, 140 
progressive  detailing  of,  55 
schedule  management  plan  and,  142 
scope  control  and,  138 

updates,  85-86,  93, 100, 140, 184, 191, 225-226,  248, 
253,  272,  284,  302,  308,  346-347,  353,  379,  385,  408, 
413-414 

Project  management  processes 
categories  of,  48-49, 418 
interactions,  50-51 , 53 
mapping  of,  422-423 
overview,  47-49 

Project  Management  Process  Groups.  See  also  Process  Groups 
definition,  554 

and  Knowledge  Area  Mapping,  422-423 
linked  by  outputs,  419 

Project  management  software,  1 54, 1 64, 1 89,  207, 225 
Project  management  staff,  555 
Project  management  system,  555 
Project  management  team,  77, 555. 

See  also  Project  team(s) 

Project  management  tools,  electronic,  300 
Project  manager  (PM) 
definition,  555 
interpersonal  skills,  17-18 
responsibilities/competencies,  1 7 
role  of,  12, 16-17 

Project  objectives,  agreed  upon,  278 
Project  organization  chart,  265,  555 
Project  performance  appraisals,  282 
Project  phases,  41-46,  555 
overlapping  of,  43 
overview,  41-42 

phase-to-phase  relationships,  42-44 
sequential  relationship,  42-43 
single-phase  project,  42 
Project  presentations,  302, 409, 415 


Project  Procurement  Management,  355-389 
definition,  555 
overview,  355-358 
Project  Quality  Management,  227-254 
See  also  Quality  management  plan 
definition,  555 
overview,  227-231 
Project  records,  302, 409, 41 5 
Project  reports,  302, 409, 41 5 
Project  requirements,  1 1 2, 1 1 8 
Project  risk,  31 0 

Project  Risk  Management,  309-354 
definition,  555 
overview,  309-312 
Project  schedule,  191, 555 
development,  142 
as  input,  187,  203,  210,  361 
as  output,  1 82-1 84 
presentation,  142 
Project  schedule  model 
development,  148 
maintenance,  148 

Project  schedule  network  diagram,  182 
definition,  555 
description  of,  159-160 
as  input,  175 

Project  scope,  1 05,  555.  See  also  Control  Scope  process; 

Define  Scope  process;  Verify  Scope  process 
Project  scope  creep,  108.  See  also  Verify  Scope  process 
Project  Scope  Management,  105-140,  555 
overview,  1 05-1 06 

Project  scope  statement,  1 05, 1 31 , 202, 21 0,  233 
assumptions  and  constraints,  168 
contents  of,  360 
definition,  556 
as  input,  127, 155, 175 
as  output,  1 23-1 24 
project  charter  and,  124 
Project  sponsor,  32 
Project  staff  assignments 
as  input,  175,  275, 281 
as  output,  272 

Project  Stakeholder  Management,  391  -41 5 
definition,  556 
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overview,  391-392 

Project  stakeholders.  See  Stakeholder(s) 

Project  statement  of  work.  See  Statement  of  work 
Project  team(s). 

colocation  of,  25, 277,  532 
composition  of,  37-38 
definition,  556 
influencing,  256 
multinational,  294 
pre-assignment  of  members,  270 
professional  and  ethical  behavior,  256 
roles  of  members  of,  36 
stakeholders  and,  30-31 
virtual,  25,  38,  271 
Project  team  directory,  556 
Project  Time  Management,  141-192 
definition,  556 
overview,  141-144 
Proposal(s).  See  Seller  proposals 
Proposal  evaluation  techniques,  375, 556 
Proprietary  rights,  369 
Prototypes,  1 1 6,  556 
Pull  communication,  295 
Push  communication,  295 
PV.  See  Planned  value 
PV  baseline  (PMB) 

Q 

QFD.  See  Quality  Function  Deployment 
Qualified  seller  list,  386 
Qualitative  analysis,  343. 

See  also  Perform  Quantitative  Risk  Analysis  process 
Quality,  228. 

See  also  Plan  Quality  process;  Seven  basic  quality  tools 
audits  for,  247,  556 
definition,  556 

Quality  assurance.  See  Perform  Quality  Assurance  process 
Quality  audits,  247, 556.  See  also  Audits 
Quality  checklists,  556 
as  input,  250 
as  output,  242 

Quality  control  measurements,  556 
as  input,  244 


as  output,  252 

Quality  function  deployment  (QFD),  1 1 4, 556 
Quality  management.  See  Project  Quality  Management 
Quality  management  and  control  tools,  240, 245-246, 556 
Quality  management  plan,  557. 

See  also  Project  Quality  Management 
as  input,  244,  321 
as  output,  241 
updates,  347 

Quality  management  system,  557 
Quality  metrics,  557 
as  input,  244,  250 
as  output,  242 
Quality  planning  tools,  527. 

See  also  Additional  quality  planning  tools 
Quality  policy,  557 
Quality  requirements,  1 1 2, 557 
Quality  standards.  See  Standard 
Quality  tools.  See  Seven  basic  quality  tools 
Quantified  risks,  prioritized  list  of,  341 
Quantitative  risk  analysis  and  modeling  techniques,  338-340, 557 
expected  monetary  value  (EMV)  analysis,  339 
modeling  and  simulation,  340 
sensitivity  analysis,  338 
Quantitative  risk  analysis  results,  trends  in,  341 
Questionnaires  and  surveys,  116,  557 

R 

RACI.  See  Responsible,  accountable,  consult  and  inform 
(RACI)  chart 

RAM.  See  Responsibility  assignment  matrix 
RBS.  See  Resource  breakdown  structure; 

Risk  Breakdown  Structure 
Rebaselining,  444.  See  also  Baseline 
Recognition  and  rewards,  266,  Til 
Records,  project,  302, 409, 415 
Records  management  system,  384, 389, 557 
Regression  analysis,  91, 103, 557 
Regulation,  557 
Regulatory  bodies,  398, 402. 

See  also  Government  regulations 
Report(s) 

information  flow  and,  59 
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project,  302, 409, 415 
work  performance,  59, 97 
Reporting  formats,  149, 200,  318 
Reporting  systems,  557 

Requested  change,  558.  See  also  Change  requests 
Request  for  information  (RFI),  68,  368, 557 
Request  for  proposal  (RFP),  68,  368, 558 
Request  for  quotation  (RFQ),  368,  558 
Requirement(s).  See  also  Product  requirements 
definition,  558 
types  of,  1 1 2 

Requirements  documentation,  558. 

See  also  Collect  Requirements  process;  Contracts 
as  input,  121,127, 134, 138,234,  361 
as  output,  1 1 7 

Requirements  management  plan,  1 1 0, 1 1 3, 1 38, 558 
Requirements  traceability  matrix,  558 
as  input,  134, 138 
as  output,  118-119 

Reserve,  558.  See  also  Management  reserve 
Reserve  analysis,  92, 1 71 , 206, 21 1 , 225, 352, 558. 

See  also  Contingency  reserve 
Residual  risk,  350, 558 

Resolution  of  conflicts.  See  Conflict  management 
Resource(s),  163, 558 
Resource  assignments,  182 
Resource  breakdown  structure  (RBS),  261 , 558 
as  input,  168, 175 
as  output,  1 65 
Resource  calendars,  558 

as  input,  163, 168,175,210,275 
as  output,  272,  378 
staffing  management  plan  and,  265 
Resource  histogram,  265-266, 559 
Resource  leveling,  179, 559 
Resource  optimization  techniques,  179-180, 189,  559 
Resource  requirements.  See  Activity  resource  requirements; 

Human  resource  requirements 
Resource  smoothing,  180,  559 
Responsibility,  264,  316, 559 
Responsibility  assignment  matrix  (RAM),  262,  559 
Responsible,  accountable,  consult,  and  inform  (RACI)  chart,  262 
Result,  559.  See  also  Deliverable(s) 

Result  transition,  103 


Reviews.  See  also  Performance  reviews;  Program  Evaluation 
and  Review  Technique 
approved  change  requests,  252, 528 
documentation,  324,  538 
peer,  252 

procurement  performance,  383,  552 
product,  135 
risk,  354 

Rewards.  See  Recognition  and  rewards 

Rework,  235,  559 

RFI.  See  Request  for  information 

RFP.  See  Request  for  proposal 

RFQ.  See  Request  for  quotation 

Risk,  559.  See  also  Negative  risks;  Opportunities; 

Positive  risks;  Threat(s) 

Risk  acceptance,  345-346, 559 
Risk  analysis.  See  also  Perform  Qualitative  Risk  Analysis 
process;  Perform  Quantitative  Risk  Analysis  process 
Risk  appetite,  31 1 , 559 
Risk  audits,  351 , 354,  559 
Risk  avoidance,  344,  559 

Risk  breakdown  structure  (RBS),  245, 317, 324, 560 

Risk  categorization,  332, 560 

Risk  category,  317, 560 

Risk  data  quality  assessment,  332, 560 

Risk  event,  52,163,203,  225 

Risk  identification.  See  Identify  Risks  process 

Risk  impact.  See  Probability  and  impact  matrix 

Risk  management.  See  also  Project  Risk  Management 

Risk  management  plan,  560. 

See  also  Plan  Risk  Management  process 
as  input,  321 , 329,  335,  343 
as  output,  316-318 
Risk  mitigation,  345,  560 
Risk  probability  and  impact,  317, 330 
Risk  reassessment,  351 , 354, 560 
Risk  register,  191, 330, 560 
identified  risks  list,  327 

as  input,  163, 168, 175,  203,  210,  234,  330,  335,  343, 
350,  361 
as  output,  1 85 
potential  responses  list,  327 
updates,  333,  341 
Risk  responses,  31 1 , 354. 
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See  also  Plan  Risk  Responses  process 
Risk  reviews,  354 
Risks,  secondary,  343, 348,  562 
Risk  score,  332 
Risk  threshold,  311, 560 
Risk  tolerance,  31 1 , 329,  560 
Risk  transference,  344, 560 
Risk  urgency  assessment,  332,  560 
Role(s),  264,316,  560 
Rolling  wave  planning,  45, 1 31 , 1 52, 560 
ROM.  See  Rough  order  of  magnitude 
Root  cause  analysis,  92, 325,  561 
Rules  of  performance  measurement,  149, 199 

s 

Safety,  267 

Salience  model,  stakeholder  analysis,  396 
Scatter  diagram,  238,  561 
Schedule,  561. 

See  also  Master  schedule;  Project  schedule; 

Schedule  model 

Schedule  baseline,  1 91 , 1 96, 233,  561 . 

See  also  Baseline  schedule;  Control  Schedule  process 
as  output,  181,385 
updates,  347 

Schedule  compression,  190,  561 
Schedule  compression  techniques 
crashing,  181 
fast  tracking,  158, 181 

Schedule  control.  See  Control  Schedule  process 
Schedule  data,  142, 191, 561 
as  input,  188 
as  output,  1 84 

Schedule  development.  See  Develop  Schedule  process 
Schedule  forecasts,  561 
as  input,  89 
as  output,  1 90 

Schedule  management  plan,  142,  561. 

See  also  Develop  Schedule  process  criteria  and  activities 
established  by,  148-149 
as  input,  1 50, 1 54, 1 62, 1 67, 1 75,  321 , 335 
updates,  191, 347 
Schedule  model,  142,  561 


Schedule  network  analysis,  561 . See  also  Backward  pass; 
Critical  chain  method;  Critical  path  method;  Resource  leveling 
Schedule  network  templates,  561 
Schedule  performance  index  (SPI),  89, 149, 189,  219, 561 
Schedule  variance  (S V),  89, 149, 189, 218,  561 
Scheduling 

methods,  142, 151 
overview,  142, 144 
Scheduling  software,  158, 177 
Scheduling  tool,  181,1 90, 561 
Scope,  562.  See  also  Product  scope;  Project  scope 
Scope  baseline,  1 01 , 1 38, 1 46, 1 96, 562.  See  also  Control 
Scope  process 
elements  of,  233 

as  input,  1 51 , 202-203,  21 0,  322,  329 
as  output,  131-132 
updates,  140,  347 
Scope  change,  48,  562 
Scope  creep,  137, 562 
Scope  management  plan,  138,  562 
as  input,  113, 121,127 
as  output,  1 09-1 1 0 

Scope  statement.  See  Project  scope  statement 

Secondary  risks,  343, 350, 562 

Selected  sellers,  377, 562 

Seller(s),  33.  See  also  Buyer-seller  relationship; 

Project  Procurement  Management 
definition,  562 

performance-related  documentation,  382 
prequalified,  361 
in  project  team,  36 
qualified  seller  list,  386 
selected,  377,  562 

Seller  performance  evaluation  documentation,  382 
Seller  proposals 
definition,  562 
as  input,  373 

Sensitivity  analysis,  338,  562 
Sequence  Activities  process,  1 41 , 432, 562 
inputs,  154-156 
outputs,  1 59-1 60 
overview,  1 53-1 54 
tools  and  techniques,  156-159 
Sequencing,  154 
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Sequential  relationship,  42-43 
Service  level  agreements  (SLAs),  70 
Seven  basic  quality  tools  (7QC  Tools),  236-239, 252, 562 
cause-and-effect  diagrams,  236 
checksheets,  237 
control  charts,  238 
flowcharts,  236 
histograms,  238 
scatter  diagrams,  238 
storyboard  illustrating,  239 
SF.  See  Start-to-finish 
Simulation,  180, 562 
Single-phase  project,  42 
SIPOC  model,  236,  237 
Slack.  See  Free  float;  Total  float 
SLAs.  See  Service  level  agreements 
Slippage,  178 

SMEs.  See  Subject  matter  experts 

Soft  logic,  158.  See  also  Discretionary  dependency 

Soft  skills,  275 

Software,  306.  See  also  Project  management  software; 
Scheduling  software 
Software  development,  116 
grade  and  quality,  228 
subsystem  interfaces,  155 
Solution  requirements,  112, 118 
Source  selection  criteria,  368-369, 373, 563 
SOW.  See  Statement  of  work 
Specification,  563 

Specification  limits,  563.  See  also  Control  limits 
SPI.  See  Schedule  performance  index 
Sponsor,  563.  See  Project  sponsor 
Sponsoring  organization,  563 
SS.  See  Start-to-start 

Staffing  management  plan,  258-259,  265-267,  563. 

See  also  Human  resource  management  plan; 

Stage  gate,  41 
Stakeholder(s),  30-33. 

See  also  Identify  Stakeholders  process;  Manage 

Stakeholder  Engagement  process;  Project  stakeholder 
definition,  563 

engagement  level  of,  402-403 
examples  of,  33 
expectations,  31 


external,  34,  54, 371, 424 
internal,  33, 54, 371, 424 
key,  93, 1 1 4, 1 1 7,  248,  277,  395 
requirements,  112, 117 
tolerances,  318 

Stakeholder  analysis,  395-397,  563 
Stakeholder  management  plan,  563 
as  input,  113, 406 
as  output,  403-404 

Stakeholder  notifications,  302, 409, 415 
Stakeholder  register,  563 

as  input,  1 1 3,  234,  291 , 322,  361 , 400 
as  output,  398, 41 4 
Standard,  563 
Start  date,  564 
Start-to-finish  (SF),  156,  564 
Start-to-start  (SS),  154, 156,  564 
Statement  of  work  (SOW),  68,  367, 564 
Statistical  sampling,  240, 252,  564 
Storyboarding,  116, 239,  246 
Strategic  planning 

organizational  strategy  and,  1 1 
statement  of  work  and,  68 
Strengths,  weaknesses,  opportunities  and  threats 
See  SWOT  analysis 
Strong  matrix  organizations,  24 
Subcontractors,  270 

Subject  matter  experts  (SMEs),  71 , 99,  31 5, 398 

Subnetwork,  564 

Subproject,  564 

Subsidiary  plans,  77,  88 

Successor  activity,  156, 158-159, 180, 564 

Summary  activity,  564 

Supplier.  See  Seller(s) 

Surveys,  116,  557 
SV.  See  Schedule  variance 
SWOT  analysis,  326,  564 
System  or  process  flow  charts,  325 

T 

T&M.  See  Time  and  Material  Contract 
Tailor,  564 
Tailoring,  48, 459 
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TCPI.  SeeTo-complete  performance  index 

Team.  See  Colocated  teams;  Develop  Project  Team  process; 

Project  management  team;  Project  team(s) 

Team-based  approaches,  171, 207 

Team-building  activities,  276 

Team  performance  assessments,  278-279, 281 

Teamwork,  274.  See  also  Develop  Project  Team  process 

Technical  documentation,  382 

Technical  documentation  updates,  348 

Technical  performance  measurement,  352 

Technique,  564 

Templates,  564 

Text-oriented  formats,  roles  and  responsibilities,  262 
Threat(s) 

definition,  564 
strategies  for,  344-345 
Three-phase  project,  42-43 
Three-point  estimate,  1 70-1 71 , 205-206, 565 
Threshold,  565 

Time  and  Material  Contract  (T&M),  364, 565 
Time  management.  See  Project  Time  Management 
Time-scaled  schedule  network  diagram,  565 
To-complete  performance  index  (TCPI),  221-222, 565 
Tolerance,  250, 565 

Tools,  300,  565.  See  also  Seven  basic  quality  tools 

Tornado  diagram,  338, 565 

Total  float,  158, 177,565 

Total  Quality  Management  (TQM),  229 

TQM.  See  Total  Quality  Management 

Training,  275 

Training  needs,  266 

Transition  requirements,  112,118 

Tree  diagram,  245, 565 

Trend  analysis,  92, 103, 188,  223,  352,  566 

Triangular  distribution,  1 71 , 206 

Trigger  condition,  566 

Tuckman  ladder  of  team  development,  276 

u 

Unanimity,  115, 566 

Union  labor/contracts,  203.  See  also  Contracts 

Updates,  change  request  for,  85 

User(s) 


customers  and,  32 
in  project  team,  36 

V 

VAC.  See  Variance  at  completion 
Validated  changes,  90, 252 
Validated  deliverables,  566 
Validate  Scope  process,  105, 453, 566 
inputs,  134-135 
outputs,  1 35-1 36 
overview,  1 33-1 34 
tools  and  techniques,  135 
Validation,  566 
Value,  business,  15-16 
Value  analysis,  122, 352. 

See  also  Expected  Monetary  Value  (EMV)  analysis 
Value  engineering,  566 
Variance,  566 

Variance  analysis,  92, 139, 189, 222, 352,  566 
Variance  at  completion  (VAC),  566 
Variation,  566 
Velocity,  566 
Vendor.  See  Seller(s) 

Vendor  bid  analysis,  207 
Vendor  conferences.  See  Bidder  conferences 
Verification,  566 
Verified  deliverables,  134 
as  input,  135 
as  output,  253 
Virtual  meetings,  84 
Virtual  project  teams 

collaboration  techniques  and,  25, 38 
virtual  team  model,  271 
VOC.  See  Voice  of  the  Customer 
Voice  of  the  Customer  (VOC),  1 1 4,  566 

w 

Watch  list,  risks  and,  330,  332,  333,  343,  347-348,  350 
WBS.  See  Work  breakdown  structure 
WBS  dictionary,  105, 132,  202,  210,  233,  360,  567 
WBS  ID,  153 

Weak  matrix  organizations,  22 
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Weighted  milestone  method,  567 

What-if  scenario  analysis,  180, 567 

Workaround,  567 

Work  authorization,  567 

Work  authorization  system,  146, 567 

Work  breakdown  structure  (WBS),  105,  202, 210. 

See  also  Create  WBS  process 
bottom-up  approach,  129 
contents  of,  360 
definition,  567 
description  of,  132, 233 
hierarchical-type  charts  and,  261 
top-down  approach,  129 
Work  breakdown  structure  component,  567 
Work  packages,  1 28, 1 50, 1 65, 567 
Work  performance  data,  59,  81 , 567 

as  input,  1 35, 1 39, 1 87,  21 7,  251 , 305,  351 , 382,  41 1 
as  output,  85 

Work  performance  information,  59,  567 
as  input,  90,  382 

as  output,  136, 139, 190,  225,  253,  307,  353,  384,  413 
Work  performance  reports,  59, 567 
as  input,  97,  281,299,  351,382 
as  output,  93 

Workshops.  See  Facilitated  workshops 
Written  documentation,  386 


©201 3 Project  Management  Institute.  4 Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOKe‘  Guide)  - Fifth  Edition 


589 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


Licensed  To:  Jorge  Diego  Fuentes  Sanchez  PMI  MemberlD:  2399412 
This  copy  is  a PMI  Member  benefit,  not  for  distribution,  sale,  or  reproduction. 


